
Prometheus reaches 1.0 - grobie
https://prometheus.io/blog/2016/07/18/prometheus-1-0-released/
======
andmarios
Congrats! Prometheus + grafana are a killer duet! Easy to setup and use. Same
goes for node_exporter. I only wish more JVM apps included a configuration
file for the jmx_exporter and an easier to setup nginx_exporter. :)

Incidentally yesterday I created a simple exporter for (linux) coretemp,
hddtemp and NUT's upsc:
[https://github.com/andmarios/sensor_exporter](https://github.com/andmarios/sensor_exporter)

~~~
rektide
I really hope upstream node_exporter is happy adding new exports!

Still slowly hacking on my homelab Prometheus bringup, but I've already got a
start developing a battery level/power supply exporter. By far the most
important Node information I want metrics and alarms on in my developer life!
[https://github.com/rektide/node_exporter/tree/export-
battery](https://github.com/rektide/node_exporter/tree/export-battery)

Almost went with a standalone Node exporter, but I decided I'd try some Go,
and tour some of the Prometheus codebase. MustNewConstMetric is a very
confusing thing to me, but hopefully I'm on the right track! Feeling double-
inspired to get my homelab Prometheus up and going right now, between renewed
excitement for these exporters and the 1.0! So close!

~~~
jrv
If the interface you're getting the metrics from is generic and standardized
enough to work on most Linux systems, it has a good chance of making it in.
"/sys/class/power_supply/..." probably fits that requirement, but bbrazil
(same name on GitHub) would be the best to give a final judgement on that kind
of thing.

~~~
jrv
Ah sorry, he is "brian-brazil" on GitHub.

------
Rapzid
Is Prometheus still pull only or is there a first class push option? This
always rubbed me the wrong way.. of course most metrics collection scrapes at
some level, but push/streaming at the infrastructure level is easier to
integrate with and compose processing pipelines with..

~~~
jrv
It's still focused on pull, while there is the Pushgateway (see
[https://prometheus.io/docs/instrumenting/pushing/](https://prometheus.io/docs/instrumenting/pushing/)
and
[https://prometheus.io/docs/practices/pushing/](https://prometheus.io/docs/practices/pushing/))
for dealing with one-off situations where you cannot scrape something. Pull
works great in most situations where people have their own private clouds or
datacenters, but it's less suitable for very restrictive environments where
you can't run Prometheus on the same network or behind the same firewall as
the targets you want to monitor.

In the usual cases, pull has many benefits however:

\- You can get high availability by simply running two identically configured,
independent Prometheus servers. No clustering required.

\- You can run a copy of production monitoring (or similar) on your laptop
without changing production. This is great for experimentation and testing
changes.

\- You get free up-ness monitoring via scrapes and can use this for alerting.

\- When there's an HTTP pull endpoint on service instances, you can also go
there manually as a human and check out the current metrics state of any
target, independent of the Prometheus server.

\- Knowledge of service identities is inverted: instead of each service
instance having to know its own identity (usually instance="hostname:port" and
some job/service name), the monitoring system knows (usually via some form of
service discovery) what instances _should_ be there and how they are labeled,
and proactively checks on them. Services have no knowledge of where the
monitoring system lives anymore, enabling the above use cases.

\- Debatable, but push-based monitoring systems can make it easier for someone
to accidentally DDoS your monitoring. (still possible with pull, but you have
one central place where you know what you pull from)

------
jrv
Prometheus cofounder here - we're happy to take any questions. Huge congrats
to everyone who made this release possible and for all the excellent work over
the years that lead up to this!

~~~
walkingolof
What is the typical user/customer of this system ? I've found it very hard to
get customers to spend time configuring a motoring system, let alone writing
any scripts to gather data.

~~~
bbrazil
I'm not sure there is a typical user. We've got everything from single-
sysadmin small companies to Fortune 500s to companies looking to integrate it
into their products.

[https://prometheus.io/blog/2016/03/23/interview-with-
life360...](https://prometheus.io/blog/2016/03/23/interview-with-life360/) and
[https://prometheus.io/blog/2016/05/01/interview-with-
showmax...](https://prometheus.io/blog/2016/05/01/interview-with-showmax/)
look at two of our users.

~~~
walkingolof
What is the business model, do you charge per input, server core or ?

~~~
jrv
No business model - Prometheus is 100% free and open-source and independent of
any one company. We have also joined the Cloud Native Computing Foundation
([https://cncf.io/](https://cncf.io/)) as the second member project after
Kubernetes: [https://cncf.io/news/announcement/2016/05/cloud-native-
compu...](https://cncf.io/news/announcement/2016/05/cloud-native-computing-
foundation-accepts-prometheus-second-hosted-project)

Read more here:
[https://prometheus.io/docs/introduction/overview/](https://prometheus.io/docs/introduction/overview/)
and here: [https://prometheus.io/community/](https://prometheus.io/community/)

------
woodcut
We've been using Prometheus in production for a while now and found it to be
rock solid, it's never an issue, never requires much of an after thought other
than extending the current use of it. All of which says a lot. Our only
"feature request" is that it stays stable and the project doesn't lose focus.
Cheers!

------
gophernaught
Hooray! Couldn't come at a better time for me, we're about to roll it out to
all our customers and the API stability promises are great news.

Many thanks to the authors for all their hard work, and congrats.

------
j_s
What is the best GitHub issue to follow to find out when Prometheus supports
events older than the configurable 5 minute limit?

I'm blocked because a network partition can mean no stats.

Edit: Maybe
[https://github.com/prometheus/prometheus/issues/398](https://github.com/prometheus/prometheus/issues/398)
? Also, limit is configurable.

~~~
jrv
That would be the correct issue about the staleness limit, yes. Note that
Prometheus does not track individual events, but only numerical time series
and their current and historical values. What's the exact use case you're
stuck on? I guess you are using the pushgateway with client-side timestamps?

~~~
j_s
Yes, I have to collect metrics in a very restricted and separated production
environment then ship them over to a completely separate system for reporting.
My impression is that Prometheus just isn't the right fit.

~~~
jrv
That depends - but yeah, those situations can be tricky sometimes.

If you are pushing metric states regularly though (more than every 5m) or
don't set client-side timestamps, that usually works though. But maybe you
have an even more special use case there regarding those metrics and the
staleness?

~~~
j_s
Basically I don't want to hassle with transferring stats until it's worth it
(collecting enough before making the transfer), rather than being forced into
streaming them due to this contstraint.

Thanks for your responses.

------
Comradin
Congratulations and thumbs up to reaching the one point ohhh

------
xvf33
I my have misread the documentation but there seems to be no way to get the
same output as the highestAverage, highestCurrent, or highestCurrent functions
from graphite.

Not sure how to filter through say 300 servers and select out the top 10 for a
particular time span. I would think that it would be a common need but I guess
I'm missing something?

~~~
jrv
Prometheus range queries work a bit differently, so this is not 100%
reproducible in a graph query, but a similar thing is possible. A given PromQL
expression is evaluated at every resolution step along the graph and doesn't
have context about what the "graph range" is. At every evaluation point, it
can still look back over a given time window, but that's more of a sliding
window approach then and independent of what the visible graph time range is.

For example, instead of highestCurrent, you could do something like:

topk(3, my_metric)

This would at every point along the graph select the current top 3 series that
have the my_metric metric name.

Or if you want to average each series over the last 10 minutes at every point
in the graph before selecting the top 3:

topk(3, avg_over_time(my_metric[10m]))

Note that due to the reasons mentioned above, topk() here does not select
whatever line has the largest area under the entire visible graph range, but
whatever is at the top at each given resolution step. So you may actually get
more than 3 series in your graph, but only 3 at a time at any given X.

There's also an issue asking about this, but we're not sure if that is
fundamentally compatible with Prometheus's query execution model without major
changes:
[https://github.com/prometheus/prometheus/issues/586](https://github.com/prometheus/prometheus/issues/586)

~~~
xvf33
I suppose what I'm asking for isn't really possible yet. Hopefully it ends up
getting implemented at some point.

Still look forward to rolling out Prometheus for all of the other great
features. Congrats on the release!

~~~
jrv
Thanks!

------
alainchabat
Is anyone using Promotheus for monitoring micro-services deployed with
Kubernetes? Any feedbacks?

~~~
netingle
We are! And unsurprising it's a great fit given k8s is inspired by Borg and
Prometheus is inspired by Borgmon.

------
akbar501
What is the scale out process with Prometheus? Is sharding/replication a
manual setup process or is it automated? What's involved in scaling out?

~~~
netingle
There is an project we've just started:
[https://docs.google.com/document/d/1C7yhMnb1x2sfeoe45f4mnnKC...](https://docs.google.com/document/d/1C7yhMnb1x2sfeoe45f4mnnKConvroWhJ8KQZwIHJOuw)

Hopefully have something to show for promcon.

------
daniel_levine
Is there a company offering a SaaS version of Prometheus?

~~~
bbrazil
There's noone presently offering that, it's designed more with a view to being
on-prem for reliability ([http://www.robustperception.io/monitoring-without-
consensus/](http://www.robustperception.io/monitoring-without-consensus/)).

~~~
daniel_levine
Understood and generally agreed. That said, often when monitoring matters most
is the exact moment when you least want to worry about the integrity or uptime
of your monitoring.

~~~
bbrazil
That's exactly our thinking, and why we want to minimise dependencies -
including internet access.

