This message was deleted.
# puppet-enterprise
s
This message was deleted.
m
of course! Primarily it was put in to aid in support team diagnostics, basically if the sysstat package is there it collects certain SAR data, so we can figure out of there are host machine or vmhost issues causing PE to not be performant
b
ok. So the collector is currently only for PE support archives?
m
Operational dash boards does actually have a few panals for this data, however, we dont collect it with telgraf, and can only be plotted when statically importing PE support archives into the operational dashboards
b
yeah, I saw those and wasn't sure if that's only for the support team or if I'm missing some telegraf config 😄
maybe the system metrics dashboard shouldn't be configured by default then? Because it's empty unless I import archives by hand?
m
Its one of those things that because we cant guarantee the presence of sysstat, and we cant manage it in PE incase someone else is already doing so,
we dont actually enable the collection by default, and we made a decision to put a little indicator in status checks to make people think about turning it on
Yeah we have had a few requests for features about enabling and disabling panals
i believe we have a ticket for it, but our next focus is building out orchestrator metrics
b
ah yes, that would be awesome
how mad is your team when the support archive has no system metrics? most customers have their own monitoring for that and we also use the operational_dashboard, customer would like to have less monitoring tools, not more 😄
c
That class also sets up collection of PE Postgresql metrics.
Metrics in the archive is hugely important for resolving performance issues. Having a performance timeline available is the difference between being able to narrow down the causes of a perf issue in one session vs. a ticket that stretches on for days or weeks.
m
for us, the team thats looking at system type metrics is rarely the team that is managing puppet, so while i assume most customers are monitoring the health of their appliance in some shape or form, when it comes time to correlate our application activities with these sytem level stats, its just way easier to collect and curate them ourselves
c
Customer monitoring is great --- and something we absolutely encourage. But, it's not accessible to us and not sharable with other internal teams that may be called in to look at an issue.
➕ 1
b
mhm true
even if the telegraf configs from the operational_dashboard would collect the same data, bumping that out of influxdb into a support archive is... ugly
c
Yeah. One key aspect of the
puppet_metrics_collector
is that it is just some SystemD timers that store off some JSON files under
/opt/puppetlabs/
. So, it shouldn't be a lot of administrative overhead.
b
https://puppet.com/docs/pe/2021.7/supported_operating_systems.html#supported_operating_systems lists some packages that are a requirement for PE, could sysstat be added? Then the collection could be enabled by default?
m
it could be yes, i think when we were putting this in we where worried about being disruptive to existing installations, but it couldn’t hurt to have it as a requirement
👍 1