In advance: I like the Grafana, Prometheus, Mimir Loki stack BUT:
I have difficulties understanding their product lineup and roadmap. Everything is named Grafana something. Grafana the company, Grafana the monitoring Frontend, Grafana Agent, Grafana Agent Flow, Grafana Agent Operator, Grafana Operator. It is easy to mix things up especially if you talk to someone who is not in the Grafana world.
They also seem to change their mind quiet fast on how users are supposed to send metrics/logs. First there was the loki, prometheus clients, then Grafana Agent Operator, then Grafana Agent Flow mode and now they announced alloy at kubecon, immediately deprecating other solutions.
All of wich do more or less the same - as far as I know.
These iterations are too fast for companies to develop trust in their solution. Even in private test clusters I have trouble catching up. And I have to confess the the new alloy solution did not make a good first impression. I dont't know why it replaces the Agent Flow mode and even worse, instead of sticking to k8s standards it uses its own custom configuration language that does not seem to have any advantages.
I hope they figure something out that works for base tasks and improve that solution over time instead of doing something new every year.
I don't blame them for using a different config language, k8s style YAML sucks, which is why half of the k8s ecosystem is tools to generate it for you. And I believe Agent and Alloy are meant to be installable outside k8s as well. I do think it would have been less confusing to just call this product Agent 3.0 instead of Alloy, but I'm not too concerned about naming decisions.
I don't understand the objection to the names. You think someone who is not in the "Grafana world" would easier understand an arbitrary name like "Thor" than "Grafana Operator"? I have no clue what Mimir is, or Loki, but "Grafana operator" is clearly a kubernetes operator for deploying Grafana. Like a "postgres operator" I read about sometime. How are things from norse mythology supposed to make it easier to understand software components and the relations between them?
Naming things is hard and I don't mind if you cant tell what a software/service does by it's name but I don't like that there so little separation between the names:
> I just deployed the Grafana Oparator, oops I ment Grafana Agent Operator
Imo at this point you're better off just using OSS not packaged by Grafana. Grafana Agent pulled in a ton of OSS as dependencies and basically implemented a service manager and config management system. However, such a big dependency tree seemed to complicate updates and also abstracted away useful config.
Fluent*/Promtail for logs and Prometheus for metrics haven't had much/any changes in the last couple years as far as I know
Agreed in all counts. They change product strategy so fast it seems like 1/2 of all links in their docs are 404s or go to something that is now deprecated.
I use grafana and Loki because those are stable. Use vector for log source and process and Prometheus for metrics and it’s much simpler!
I have difficulties understanding their product lineup and roadmap. Everything is named Grafana something. Grafana the company, Grafana the monitoring Frontend, Grafana Agent, Grafana Agent Flow, Grafana Agent Operator, Grafana Operator. It is easy to mix things up especially if you talk to someone who is not in the Grafana world.
They also seem to change their mind quiet fast on how users are supposed to send metrics/logs. First there was the loki, prometheus clients, then Grafana Agent Operator, then Grafana Agent Flow mode and now they announced alloy at kubecon, immediately deprecating other solutions. All of wich do more or less the same - as far as I know.
These iterations are too fast for companies to develop trust in their solution. Even in private test clusters I have trouble catching up. And I have to confess the the new alloy solution did not make a good first impression. I dont't know why it replaces the Agent Flow mode and even worse, instead of sticking to k8s standards it uses its own custom configuration language that does not seem to have any advantages.
I hope they figure something out that works for base tasks and improve that solution over time instead of doing something new every year.