You can look out for Prometheus Instrumentation (https://prometheus.io/docs/practices/instrumentation/) Client Library available in various languages https://prometheus.io/docs/instrumenting/clientlibs/ to create the custom metric you need for AS4000 and then Grafana can query the newly instrumented metric to show on the dashboard.

If you're already using Prometheus for your system metrics, then it seems like standing up Elasticsearch just for Linux host monitoring is excessive. The node_exporter is probably sufficient if you'e looking for standard system metrics.

Another thing to consider is that Metricbeat / ELK use a push model for metrics delivery, whereas Prometheus pulls metrics from each node it is monitoring. Depending on how you manage your network security, opting for one solution over two may make things simpler.

Hi Sunil! Unfortunately, I don´t have much experience with Metricbeat so I can´t advise on the diffs with Prometheus...for Linux server, I encourage you to use Prometheus node exporter and for PCF, I would recommend using the instana tile (https://www.instana.com/supported-technologies/pivotal-cloud-foundry/). Let me know if you have further questions! Regards Jose

I work at Volvo Car Corporation as a consultant Project Manager. We have deployed Zabbix in all of our factories for factory monitoring because after thorough investigation we saw that Zabbix supports the wide variety of Operating Systems, hardware peripherals and devices a Car Manufacturer has.

No other tool had the same amount of support onboard for our production environment and we didn't want to end up using a different tool again for several areas. That is the major strong point about Zabbix and it's free of course. Another strong point is the documentation which is widely available; Zabbix Youtube channel with tutorial video's, Zabbix share which holds free templates, the Zabbix online documentation and the Zabbix forum also helped us out quite a bit. Deployment is quite easy since it uses templates, so almost all configuration can be done on server side.

To conclude, we are really pleased with the tool so far, it helped us detect several causes of issues that were a pain to solve in the past.

Centreon is part of the Nagios ecosystem, meaning there is a huge number of resources you may find around in the community (plugins, skills, addons). Zabbix monitoring paradigms are totally different from Centreon. Centreon plugins have some kind of intelligence when they are launched, where Zabbix monitoring rules are configured centrally with the raw data collected. Testing both will help you understand :) Users used to say Centreon may be faster for setup and deployment. And in the end, both are full of monitoring features. Centreon has out of the box a full catalog of probes from cloud to the edge https://www.centreon.com/en/plugins-pack-list/ As soon as you have defined your monitoring policies and template, you can deploy it fast through command line API or REST API. Centreon plays well in the ITSM, Automation, AIOps spaces with many connectors for Prometheus, ServiceNow, GLPI, Ansible, Chef, Splunk, ... The polling server mode is one of the differentiators with Centreon. You set up remote server(s) and chose btw multiple information-exchange mechanisms. Powerful and resilient for remote, VPN, DMZ, satellite networks. Centreon is a good value for price to do a data collection (availability, performance, fault) on a wide range of technologies (physical, legacy, cloud). There are pro support and enterprise version with dashboards and reporting. IT Central Station gathers many user feedback you can rely on both Centreon & Zabbix https://www.itcentralstation.com/products/centreon-reviews  

We highly recommend Zabbix. We have used it to build our own monitoring product (available on cloud -like datadog- or on premise with support) because of its flexibility and extendability. It can be easily integrated with the powerful dashboarding and data aggregation of Grafana, so it is perfect. All configuration is done via web and templates, so it scales well and can be distributed via proxies. I think there also more companies providing consultancy in Zabbix (like ours) than Centreon and community is much wider. Also Zabbix roadmap and focus (compatibility with Elasticsearch, Prometheus, TimescaleDB) is really really good.

Hi Vivek, what's your stack? If huge monitoring bills are your concern and if you’re using a number of JVM languages, or mostly Scala / Akka, and would like “one tool to monitor them all”, Kamon might be the friendliest choice to go for.

Kamon APM’s major benefit is it comes with a built-in dashboard for the most important metrics to monitor, taking the pain of figuring out what to monitor and building your own dashboards for weeks out of the monitoring.

https://kamon.io/apm/

I worked with Datadog at least one year and my position is that commercial tools like Datadog are the best option to consolidate and analyze your metrics. Obviously, if you can't pay the tool, the best free options are the mix of Prometheus with their Alert Manager and Grafana to visualize (that are complementary not substitutable). But I think that no use a good tool it's finally more expensive that use a not really good implementation of free tools and you will pay also to maintain its.

this is quite affordable and provides what you seem to be looking for. you can see a whole thing about the APM space here https://www.apmexperts.com/observability/ranking-the-observability-offerings/

For our Predictive Analytics platform, we have used both Grafana and Kibana

• Grafana based demo video: https://www.youtube.com/watch?v=tdTB2AcU4Sg
• Kibana based reporting screenshot: https://imgur.com/vuVvZKN

Kibana has predictions and ML algorithms support, so if you need them, you may be better off with Kibana . The multi-variate analysis features it provide are very unique (not available in Grafana).

For everything else, definitely Grafana . Especially the number of supported data sources, and plugins clearly makes Grafana a winner (in just visualization and reporting sense). Creating your own plugin is also very easy. The top pros of Grafana (which it does better than Kibana ) are:

• Creating and organizing visualization panels
• Templating the panels on dashboards for repetetive tasks
• Realtime monitoring, filtering of charts based on conditions and variables
• Export / Import in JSON format (that allows you to version and save your dashboard as part of git)

I use both Kibana and Grafana on my workplace: Kibana for logging and Grafana for monitoring. Since you already work with Elasticsearch, I think Kibana is the safest choice in terms of ease of use and variety of messages it can manage, while Grafana has still (in my opinion) a strong link to metrics

After looking for a way to monitor or at least get a better overview of our infrastructure, we found out that Grafana (which I previously only used in ELK stacks) has a plugin available to fully integrate with Amazon CloudWatch . Which makes it way better for our use-case than the offer of the different competitors (most of them are even paid). There is also a CloudFlare plugin available, the platform we use to serve our DNS requests. Although we are a big fan of https://smashing.github.io/ (previously dashing), for now we are starting with Grafana .

I use Kibana because it ships with the ELK stack. I don't find it as powerful as Splunk however it is light years above grepping through log files. We previously used Grafana but found it to be annoying to maintain a separate tool outside of the ELK stack. We were able to get everything we needed from Kibana.

Kibana should be sufficient in this architecture for decent analytics, if stronger metrics is needed then combine with Grafana. Datadog also offers nice overview but there's no need for it in this case unless you need more monitoring and alerting (and more technicalities).

I use Grafana because it is without a doubt the best way to visualize metrics

@Kibana, of course, because @Grafana looks like amateur sort of solution, crammed with query builder grouping aggregates, but in essence, as recommended by CERN - KIbana is the corporate (startup vectored) decision.

Furthermore, @Kibana comes with complexity adhering ELK stack, whereas @InfluxDB + @Grafana & co. recently have become sophisticated development conglomerate instead of advancing towards a understandable installation step by step inheritance.