adding freertr to exporters.md as it just got a built-in, user configurable exporter for all the show commands it have#1759
adding freertr to exporters.md as it just got a built-in, user configurable exporter for all the show commands it have#1759mc36 wants to merge 1 commit intoprometheus:masterfrom mc36:patch-1
Conversation
|
the exporter itself can be found here: http://sources.nop.hu/src/serv/servPrometheus.java |
|
I can't find any Prometheus instrumentation in this code base from a quick look, nor any mention of the Java client which Java code should be using for direct instrumentation/exposition, nor the appropriate content-type if you were exposing by hand. Can you explain more about what this is doing, and how you would use it to get Prometheus metrics exposed? |
hi,
|
| category | value |
|---|---|
| CommittedVirtualMemorySize | 7393935360 |
| FreePhysicalMemorySize | 8156749824 |
| ProcessCpuLoad | 0.007719799857040743 |
| ProcessCpuTime | 250260000000 |
| SystemCpuLoad | 0.09049320943531093 |
| SystemLoadAverage | 1.84 |
| ____________________________ | ______________________ |
services>
7:
services>show prometheus home sys | begin result
result:
HELP system_CommittedVirtualMemorySize_cnt column 1 of sho watchdog sys | exc name
TYPE system_CommittedVirtualMemorySize_cnt gauge
system_CommittedVirtualMemorySize_cnt 7389724672
HELP system_FreePhysicalMemorySize_cnt column 1 of sho watchdog sys | exc name
TYPE system_FreePhysicalMemorySize_cnt gauge
system_FreePhysicalMemorySize_cnt 8070684672
HELP system_ProcessCpuLoad_cnt column 1 of sho watchdog sys | exc name
TYPE system_ProcessCpuLoad_cnt gauge
system_ProcessCpuLoad_cnt 0.2727272727272727
HELP system_ProcessCpuTime_cnt column 1 of sho watchdog sys | exc name
TYPE system_ProcessCpuTime_cnt gauge
system_ProcessCpuTime_cnt 266800000000
HELP system_SystemCpuLoad_cnt column 1 of sho watchdog sys | exc name
TYPE system_SystemCpuLoad_cnt gauge
system_SystemCpuLoad_cnt 0.16666666666666666
HELP system_SystemLoadAverage_cnt column 1 of sho watchdog sys | exc name
TYPE system_SystemLoadAverage_cnt gauge
system_SystemLoadAverage_cnt 1.71
services>
|
That's not a exposing data in a form that Prometheus can scrape, to be part of this list it'd need to expose it over HTTP. The _cnt on all those metrics is also confusing. |
|
hi, show prometheus home | begin result and finally, thanks for spotting the _cnt appending in the small sample, regards,
|
|
typo: |
|
I'm not following, does this expose metrics over HTTP or not? Is there documentation explaining how to use this? |
|
yesss for sure it replies via http and prometheus scrapes it correctly! |
|
Is there any documentation about how a user would enable this and use it with Prometheus? Those links contain nothing about this topic. Many of those metrics appear to have what should be labels in metric names, for example bfd6_2001_db8_57__2_state, iface_hwcntr_hairpin71_state, and routing_bgp4_65535_neighbors. This limits the usefulness of these metrics, so should be moved to labels. |
|
hi, regarding the documentation, currently we have no user's guide on the above mentioned tech blog but there |
|
typo: |
Actually for direction the metric name is usually the right thing to do, as it's rare you'd want to aggregate across both directions as almost everything is duplex these days. |
|
hi, we already have some sample configs at http://sources.nop.hu/misc/prometheus/ in the txt files but. i've cooked some examples (1) for you that produce human-friendly amount of metrics and we'll take your very useful clarifications into account about what fields should be label or part we're waiting for you useful comments! thanks, 1: 2: 3: 4: 5: 6: |
|
hi, |
|
I'm concerned that there's no docs on how to use this, and even then it seems to require far more work on the part of the user than it should as this is more exposing a metrics conversion framework than metrics. The most configuration a user should have to do for typical metrics is enabling/disabling specific sets of metrics if they're expensive. They shouldn't have to decide how the metrics are named, or what goes in labels or not - all of that should be determined by the developers and hardcoded. Doing otherwise is not only unnecessary complexity for users, but also prevents sharing dashboards and rules by users. 5 is the closest to what the metrics should look like label wise, though testing_iface_tx is not very informative as a metric name. Whether that is bytes, packets, or something else should also be mentioned in the name. |
beorn7
added
the
exporters and integrations
|
hi, first of all, i would like to thank you for spotting the interface finally we got the other missing pieces you mentioned: you can use the same dashboard for all the link state routing protocols services>show running-config all | count services>show running-config prometheus | count services> so imho this exporter does not put more configuration task and we're doing similar things here except that we're the router, your opinion that it's a metric exposer framework in freertr is correct. and similarly to the snmp case, you wont use all the oids at once as most and an additional reason for the framework is that most of the show commands in similarly, the bgp consistency check is an expensive calculation that performed by and link state routing protocols also have a trick, we can perform the dijkstra and as we talked about streaming telemetry, those metrics are described in yang files, so in my opinion, we're doing similar things here. that is, exposing thanks, kaputt.debrecen3#show ipv4 bgp 1955 unicast summary kaputt.debrecen3#show ipv4 bgp 1955 unicast database | count kaputt.debrecen3#show ipv4 bgp 1955 unicast database | first 15 sid#show ipv4 bgp 1955 unicast summary sid#show ipv4 bgp 2 unicast summary sid#show ipv4 bgp 2 unicast database | count sid#show ipv4 bgp 2 unicast database | first 30 sid#show ipv4 bgp 2 unicast database 1.0.4.0/22 sid# |
My point is that none of this should need to be configured by the user at all, it should Just Work.
The SNMP exporter is a generic exporter. It designed to work with the vast majority of SNMP devices there from a wide variety of vendors, including multiple interesting interpretations of the RFCs. The goal of an exporter should be to require as little configuration as possible, which in the happy case for the SNMP exporter is just knowing which OID trees you care about. The SNMP exporter does not require you to configure all of your metric and label names, as we can automatically determine this from the MIBs. An ideal exporter doesn't need any per-metric configuration at all, you only need tell it what to talk it. This here is not a generic exporter, it is the built-in metrics exposition of a single vendor's application where they have full knowledge and control of the code. The user configuration required here should be at most opting in/out of specific sets of metrics.
By default you should expose everything, Prometheus is quite efficient after all. Only for high cardinality metrics should the option to enable/disable metrics come up.
That's a pretty normal part of providing metrics to your users, they rarely come for free. That's also only one way to implement it, the issue I see with your current approach is how it requires user configuration for things that should be hardcoded by the vendor.
You are the vendor here, you can ensure your code is sufficiently efficient that you don't have to artificially limit the usefulness of the exposed metrics.
That would be the sort of thing to disable by default, as that's very high cardinality.
That sounds like blackbox monitoring, which should not be tied into whitebox metrics exposition. Metrics exposition from an application should focus on what the application already knows internally, not reaching out to 3rd party systems or performing expensive calculations. I'd suggest focusing on getting the basic and simple metrics working easily out of the box, rather than over-generalising the problem and requiring users to copy&paste boilerplate configuration to get any useful metrics. |
4 participants
No description provided.