Sorry, we generally do not have a place for tutorials like this on our
site. There are thousands of such tutorials out there, it would be
impossible to curate them from our site.
As a TrueNAS SCALE user, I wish SCALE itself had better Prometheus support.
I've thought about adding some to the
+1 to keeping consistent with the other libraries.
We should clarify the docs that `time` is an ok value in addition to
`timestamp`.
On Mon, Sep 4, 2023 at 2:44 PM Julius Volz wrote:
> Since that's a metric that is standardized across our client libraries, we
> should keep the existing name
We've done at least one rewrite of the parser in the past. We do
substantial changes to our subsystems all the time. For example, the
"stringlabels" changes were a recent substantial change to the internals of
in-memory label storage.
The only things we want to avoid is breaking existing users
Hey all,
We have a lot of exporter projects in both Prometheus and
Prometheus-Community GitHub.
There's lots of backlog of things to do.
* Triage issues.
* Review PRs.
* Improve update automation.
* Make new releases.
I've been thinking about how to handle some of this workload and had the
idea
Although, I haven't actually checked to see if negative timestamps are
supported.
On Mon, Mar 27, 2023 at 3:38 PM Ben Kochie wrote:
> Prometheus timestamps are in int64 (signed) milliseconds. So the maximum
> number of data points per series is: 9,223,372,036,854,775,807
>
> On
Prometheus timestamps are in int64 (signed) milliseconds. So the maximum
number of data points per series is: 9,223,372,036,854,775,807
On Mon, Mar 27, 2023 at 3:24 PM Stuart Clark
wrote:
> On 2023-03-27 14:10, Abdelouahab Khelifati wrote:
> > I mean the maximum number of datapoints per time
03, 'd02', 0.54, 0.24, ... , 0.34*
> *2022--01-03, 'd04', 0.35, 0.94, ... , 0.53*
> *2022--01-04, 'd02', 0.59, 0.22, ... , 0.95*
> *...*
>
> Best,
> Abdel
>
>
> On Monday, March 27, 2023 at 11:25:43 AM UTC+2 Ben Kochie wrote:
>
>> You will want to convert th
You will want to convert the CSV to OpenMetrics format.
See:
https://prometheus.io/docs/prometheus/latest/storage/#backfilling-from-openmetrics-format
On Mon, Mar 27, 2023 at 11:18 AM Abdelouahab Khelifati
wrote:
> Hello all,
>
> How can I load a huge csv file into Prometheus? I tried
>
It was my understanding that license changes, can be done by the copyright
holder, without consent of all contributors. Because they do not hold any
copyright to the code. IIRC this is how Grafana was able to relicense from
Apache to AGPL. They did not need to get consent from all contributors.
YES
On Mon, Dec 5, 2022 at 11:44 AM Julien Pivotto
wrote:
> Dear Prometheans,
>
> As per our governance [1], "any matter that needs a decision [...] may
> be called to a vote by any member if they deem it necessary."
>
> I am therefore calling a vote to promote Prometheus-community's Windows
>
avoid this
situation.
On Mon, Nov 28, 2022 at 3:38 PM Ben Kochie wrote:
> On Mon, Nov 28, 2022 at 1:40 PM l.mi...@gmail.com
> wrote:
>
>> I agree that this is not side-effect free. With the worst possible
>> outcome of sending bogus alerts.
>> But.
>> We're talking
On Mon, Nov 28, 2022 at 1:40 PM l.mi...@gmail.com
wrote:
> I agree that this is not side-effect free. With the worst possible outcome
> of sending bogus alerts.
> But.
> We're talking about metrics, so from my PoV the consequences range not
> from "annoying to dangerous" but "annoying to more
Yes, build it in. We don't want to require sidecars for every exporter.
On Mon, Nov 28, 2022 at 12:43 PM Stuart Clark
wrote:
> On 2022-11-28 11:40, Ben Kochie wrote:
> > It depends on if the sidecar is with Prometheus or with the target.
> >
> > If it's with Prometheus,
It depends on if the sidecar is with Prometheus or with the target.
If it's with Prometheus, that's probably just a docs update.
If it's with every exporter, that's probably something we would want in the
exporter-toolkit.
But, my understanding was that the typical thing here was to use mTLS
Soft / partial failure modes can be very hard problems to deal with. You
have to be a lot more careful to not end up missing partial failures.
While it seems like having a soft sample_limt is good, and the hard
sample_limit is bad. The "Fail fast" will serve you better in the long run.
Most of
This is available in the new Go runtime metrics, you can enable it in your
application with a runtime metrics filter.
https://github.com/prometheus/client_golang/blob/9801a4e3ceb49d24dfaf4fa6fc8c2d58aa3b2dc9/prometheus/collectors/go_collector_latest_test.go#L284
You'll probably want
Hey, that would be a great feature to have.
I would start by opening an issue on the exporter repo.
I also have this need, and have been starting the work to refactor the AWS
code in Prometheus to support "roles" like the kubernetes_sd_configs so we
can add direct support for something like
Seems fine to me.
Two requirements that come to mind:
* We need a "machine" level executor, for some builds that don't work well
in Docker.
* We need a stackable containers/compose type for some integration tests,
for example MySQL and Postgres exporters.
I have not looked into how those work
I looked into this a while back and didn't find a good API / tool to
automatically push updates.
Maybe things have improved since I last tried.
On Wed, Feb 2, 2022, 17:01 Julien Pivotto
wrote:
>
> Hello,
>
> Someone pointed out on twitter that our Docker Hub readme was not
> useful to run
YES
On Thu, Jan 20, 2022 at 3:41 PM Julien Pivotto
wrote:
> Dear Prometheans,
>
> As per our governance, I'd like to cast a vote to rename the Blackbox
> Exporter to Prober.
> This vote is based on the following thread:
>
>
The exporter consumes almost no resources. It should not be resource
impacting.
Just run the exporter 1:1 with your nodes, this is the correct design, It
means you are communicating over localhost with the mariadb process, which
allows you to improve security by restricting the exporter user to
And to add to this, for the case of managed MySQL where the sidecar is not
possible, we can add multi-target exporter support.
https://prometheus.io/docs/guides/multi-target-exporter/
There's a partial implementation of this in a PR on the exporter, but the
author has not responded to feedback
Your second query is using not-equals. I would expect it to return all
metrics names that do not have job="prometheus". Seems to be
working correctly.
On Fri, Dec 10, 2021 at 9:10 AM Amey Barve wrote:
> We want to get all metric names from Prometheus server filtered by a
> particular label.
>
>
There are lots of ways to easily inject secrets into configs.
Adding secrets/headers via config file is the safest way.
While I'm all for allowing sharp edges in tools if they're not default, I'm
strongly against having known unsafe things like secrets on the command
line.
On Tue, Nov 23, 2021
On Mon, Nov 22, 2021 at 4:03 PM Tony Di Nucci wrote:
> Thanks for the feedback Stuart, I really appreciate you taking the time
> and you've given me reason to pause and reconsider my options.
>
> I fully understand your concerns over having a new data store. I'm not
> sure that AlertManager and
w features to the
existing Alertmanager clustering framework.
On Sat, Nov 20, 2021 at 11:29 AM Ben Kochie wrote:
> What gives you the impression that the Alertmanager is "best effort"?
>
> The alertmanager provides a reasonably robust HA solution (gossip
> clustering).
What gives you the impression that the Alertmanager is "best effort"?
The alertmanager provides a reasonably robust HA solution (gossip
clustering). The only thing best-effort here is actually deduplication. The
Alertmanager design is "at least once" delivery, so it's robust against
network
Thanos automatically deals with downsample lookback with no changes. This
was fixed at least 2 years ago.
On Mon, Nov 15, 2021, 18:54 Julien Pivotto
wrote:
> We are willing to have downsampling in Prometheus too in the future.
>
> I would merge that pull request.
>
> Le lun. 15 nov. 2021,
+1, the formatting changes look nice.
On Thu, Oct 21, 2021 at 10:36 AM Julien Pivotto
wrote:
> On 21 Oct 01:33, Mateusz Gozdek wrote:
> > Hi all,
> >
> > While recently contributing for the first time to Prometheus code base,
> > I've noticed that the Go source files could be more consistently
Yup, Prometheus is a monitoring system, not a general use time-series
database.
Specifically, Prometheus has a "look back window" where Prometheus will
take the timestamp of your query and look back in time for samples to match.
This is fundamental to how PromQL works.
So no, what you are
The fork owner can make a manual request to github to mark the repo as not
a fork. It's pretty easy to do, I've done this for several other projects.
On Wed, Aug 18, 2021 at 12:54 PM Bjoern Rabenstein
wrote:
> On 18.08.21 12:03, Julien Pivotto wrote:
> > We should graveyard it. If you are
+1 to mark archived.
Manually graveyarding things isn't really needed anymore unless we really
want to break use of a thing.
On Tue, Aug 17, 2021 at 10:54 AM Matthias Rampke
wrote:
> I think the no-magic route is better. You can also archive the repo[0] to
> make it clear that it's read only
Please use the users email list for help requests. This list is for
developer topics.
On Thu, Jul 15, 2021 at 1:24 PM Mithun Batabyal
wrote:
> Hi Team,
>
> we are using Prometheus and grafana combination for monitoring in out
> toyota project.
> we want to increase data retention time from
We've talked about making build-time plugins possible. Specifically for
service discovery methods because some of them are very large/bloated due
to vendored code.
A build time interface like Caddy or CoreDNS for other functions would be
interesting.
On Tue, Jul 13, 2021 at 6:50 AM Darshan
Is anyone using this kind of thing in production? I've seen lots of demos
and promises over the years. Every anomaly detection project seems to be
abandoned after 6 months.
I'd like to avoid adding functionality that is "cool" but has no practical
application.
For example:
This is not a development topic. Please use our support community.
https://prometheus.io/community/
On Thu, Jun 24, 2021 at 1:29 PM Mithun Batabyal
wrote:
> Hi Team,
>
> im using Prometheus and grafana as part of monitoring and deployed
> through helm charts.
>
> currently we have default
Check out the "help wanted" label on github.
https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Aprometheus+label%3A%22help+wanted%22
On Fri, Jun 4, 2021 at 8:38 AM Rs coding wrote:
> I am a beginner in this project anyone can suggest to me beginner-friendly
> issues.
>
>
YES
On Thu, Mar 25, 2021 at 11:07 PM Julien Pivotto
wrote:
> Hereby I am calling a vote to allow the expansion on environment
> variables in the prometheus configuration file.
> Because it can be seen as an override of a previous vote[1], I am calling a
> new vote for this specific part.
>
>
I like the idea of making client_golang have more "APM" like features. I'm
not sure this would be something to enable by default, but having a central
place for these things makes sense to me.
On Tue, Mar 23, 2021 at 11:24 AM Matthias Rampke
wrote:
> Ah, even before following the link I had
Sorry, but this doesn't seem like any real improvement over the tooling we
already have. We're already CI vendor portable. We converted from Travis to
Circle long ago, our build steps just aren't that complicated. Everything
is in a standardized Makefile system. Adding more abstraction wrappers
This sounds awesome to me. I'm glad to see some Prometheus love from the Go
team.
If you would please file an issue on the client_golang project, with some
more details on the specific changes you want to make, that would be
perfect.
Looking forward to seeing this added.
On Sat, Mar 6, 2021 at
import multiple ones into
>>> the same project. So with that in mind I like "-mixin".
>>>
>>> But we could be more consistent about root-of-repo vs docs vs
>>> documentation directories...
>>>
>>>
>>> Tom
>>>
>>>
We currently have mixins spread out over various paths within each
repository. It would be nice if there was a standard path for this.
What do people think of having all projects keep their mixins in
`/monitoring-mixin`?
alertmanager/doc/alertmanager-mixin
mysqld_exporter/mysqld-mixin
If a remote write receiver is unable to ingest, wouldn't this be something
to fix on the receiver side? The receiver could have a policy where it
drops data rather than returning an error.
This way Prometheus sends, but doesn't have to need to know or deal with
ingestion policies. It sends a bit
On Mon, Feb 22, 2021 at 3:48 AM Marcelo Magallón <
marcelo.magal...@grafana.com> wrote:
> Thanks Ben.
>
> On Thu, Feb 18, 2021 at 1:37 PM Ben Kochie wrote:
>
>> The problem with what you're proposing is you're getting an invalid
>> picture of data over time. This is
Prometheus absolutely does do dynamic discovery.
See the scrape_config section of the docs:
https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config
There are 16 available XXX_sd_configs options there. If your source of
truth isn't listed, you can either write your
The problem with what you're proposing is you're getting an invalid picture
of data over time. This is the problem with the original smokeping program
that the smokeping prober is trying to solve.
The original smokeping software does exactly what you're talking about. It
sends out a burst of 10
http://gph.is/1TFACgU
On Wed, Feb 10, 2021 at 7:21 PM Bjoern Rabenstein
wrote:
> Hi Prometheans,
>
> tl;dr: I have just published a draft of a design document about
> better histograms for Prometheus and would appreciate your feedback:
>
>
I think the point is that commvault only implements traps, and has no
metrics that can be polled via the snmp_exporter.
In this case, Prometheus is not really a possible monitoring solution, as
it's not an event store.
On Thu, Jan 28, 2021 at 11:43 PM Stuart Clark
wrote:
> On 28/01/2021 13:02,
That's proposal #4.
On Sun, Jan 31, 2021 at 5:31 PM Gabriel Cavalcante <
gabriel.cavalcant...@gmail.com> wrote:
> Is it possible to use the scratch image with Prometheus binary inside
> only? That would reduce the surface entirely.
>
> On Sun, 31 Jan 2021 at 13:26 Julien Pivotto
> wrote:
>
>>
Another option is we could fully build our own busybox binary, with the
necessary fixes.
I'm somewhat in favor of going distroless. With a large number of users
using our container images in Kubernetes, it's less necessary to include
busybox, as they can attach userspace sidecar containers.
On
cussed this in
>> the
>> > past.
>>
>> How would you merge release branches in master?
>>
>> >
>> > Kind Regards,
>> > Bartek Płotka (@bwplotka)
>> >
>> >
>> > On Thu, 3 Dec 2020 at 14:20, Brian Brazil <
>>
I'd like to adjust our defaults for GitHub merging settings:
Right now, we allow all three modes for PR merges.
* Merge commits
* Squash merging
* Rebase merging
Proposal: Remove rebase merging (aka fast-forward merges) so that we stick
to merge/squash and merge.
[image: image.png]
--
You
I think that PR link is incorrect.
Yes, I think we should consider dropping 32-bit official builds. Unless we
can reduce the amount of mmap'd data.
One thing I noticed when running on a 32-bit machine a while back was that
the mmap'd data is mapped multiple times for different OS threads.
Yes, we should apply and get more details on the new FOSS plans.
Anyone volunteer to take that on?
On Wed, Aug 26, 2020 at 10:59 AM Julius Volz wrote:
> On Wed, Aug 26, 2020 at 10:16 AM Johannes Ziemke
> wrote:
>
>> Hi everyone,
>>
>> as mentioned in chat yesterday, Docker will limit the
I would start with an issue on the repo.
On Fri, Jul 31, 2020 at 2:51 PM Danny Smith wrote:
> I've recently had to build node_exporter for an Oracle Solaris system, and
> noticed that the 'Solaris' support is actually currently
> Illumos/OpenIndiana support. Both systems have different sets of
I'm with Brian and Julian on this.
Multi-tenancy is not really something we want to solve in Prometheus. This
is a concern for higher level systems like Kubernetes. Prometheus is
designed to be distributed. If you have targets with different needs, they
need to have separate Prometheus instances.
Hey all.
In order to help make the node_exporter more useful, sometimes we like to
reduce the number of metrics it outputs by default. This helps by reducing
the load on Prometheus, especially for users with large numbers of nodes.
To help with this, I'm proposing[0] we add an include/exclude
Nice.
On Thu, Jul 2, 2020 at 12:21 PM Julien Pivotto
wrote:
> MySQL had decided
>
> https://mysqlhighavailability.com/mysql-terminology-updates/
>
>
> Le mer. 1 juil. 2020 à 09:54, Matthias Rampke a
> écrit :
>
>> +1 for changing the default branch, +1 to seeing what GitHub does to help
>> us,
Similar, GitLab supports webhooks directly into Issues, and a new incident
management system.
On Tue, Jun 30, 2020 at 5:06 PM Julien Pivotto
wrote:
> On 28 Jun 07:17, Josh Wolff wrote:
> > Oh, great, thank you for pointing me to these links!
> >
> > On Sunday, June 28, 2020 at 12:42:09 AM
It was mentioned[0] that we could apply for Google Season of Docs[1]. The
idea would be to add additional documentation about exposed metrics for
various exporters. Especially common things like the blackbox_exporter, and
node_exporter.
I'm interested in this, is anyone else?
[0]:
One subject that I don't see covered in the doc is spacing. There are
several places where whitespace is optional, and it would be good to have a
consistent opinion on it.
* Between label selectors {foo="foo",bar="bar"} vs {foo="foo", bar="bar"}
* Between params: histogram_quantile(0.9,
+1 for "prober". We could call it simply "prober". It more directly
describes what it's doing.
On Thu, Jun 11, 2020 at 12:35 PM Julius Volz wrote:
> Btw. in case we do end up going for a rename, I think Probe Exporter or
> Prober Exporter would be a nice and descriptive name for what it's
I'm planning to do the flag name change to the node_exporter soon.
I also am not sure about blackbox/whitebox.
How about this proposal: replace "whitebox" with "internal". This better
describes what we really mean, removes the black vs white connotations, and
simplifies the change.
On Thu, Jun
I'd like to enable Dependabot on prometheus/prometheus, specifically to
automatically handle the React UI version bumps. This will deal with the
small version bumps for all the random security vulnerabilities that pop up.
The bot will create PRs like this one:
YES
On Thu, May 28, 2020 at 8:52 PM Bjoern Rabenstein
wrote:
> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
>
YES
On Thu, May 28, 2020 at 9:30 PM Julius Volz wrote:
> Dear Prometheans,
>
> https://github.com/prometheus/docs/pull/1640 proposes to list an exporter
> for Fortigate devices that uses a REST API. Brian's stance so far has been
> to only add exporters for metrics that cannot be already
I was thinking about building an "exporter kit" repo that would include
some helpful functions to reduce the amount of boilerplate needed to write
exporters.
Perhaps we could star this project, have the https code moved there?
github.com/prometheus/exporter/https
On Wed, May 27, 2020 at 12:00
+1 for IETF Rough consensus
On Mon, May 25, 2020 at 2:04 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:
> Dear all,
>
> as most of you know, the Prometheus governance[1] has three levels of
> formalized decision making. In increasing order of strength and
> requirements, they are:
>
Adding Prometheus users as well.
On Fri, May 8, 2020, 16:10 Julius Volz wrote:
> Hi everyone,
>
> By some historic accident I became the maintainer of the collectd exporter
> (https://github.com/prometheus/collectd_exporter), although I have never
> used collectd myself and know very little
For Chef users, people typically implement Chef search based templates and
file_sd_configs.
IMO, there's no real point into adding Chef support directly into
Prometheus. Chef searches are too slow/expensive to add directly to
something that might send multiple queries every 30-60 seconds.
On
Yes, let's release right away.
On Thu, Apr 23, 2020 at 1:41 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:
> Dear all,
>
> This is a call for consensus within Prometheus-team on releasing
> node_exporter 1.0.0 as-is.
>
> node_exporter 1.0.0-rc.0 has been cut on 2020-02-20[1]. It
https://about.gitlab.com/solutions/github/
On Thu, Apr 9, 2020 at 10:05 AM Bartłomiej Płotka
wrote:
> Nice! I guess you cannot use GitLab CI while having repo on GitHub? 樂
>
> Bartek
>
> On Thu, 9 Apr 2020 at 08:50, Ben Kochie wrote:
>
>> Something, something, gitlabci[
anged or something.
>
> Bartek
>
> On Thu, 9 Apr 2020 at 08:01, Ben Kochie wrote:
>
>> Seems like a good idea to me. It can also run the tests in parallel.
>>
>> On Wed, Apr 8, 2020 at 11:23 PM Julien Pivotto
>> wrote:
>>
>>>
>>&
Seems like a good idea to me. It can also run the tests in parallel.
On Wed, Apr 8, 2020 at 11:23 PM Julien Pivotto
wrote:
>
> Hi there,
>
> What would you think of splitting React and Golang tests in 2 different
> circleci jobs?
>
> React is not predictable as we don't really pin dependencies,
Are you sure you're not looking for inhibit rules?
https://prometheus.io/docs/alerting/configuration/#inhibit_rule
This allows one alert to inhibit another alert from firing.
On Fri, Mar 13, 2020 at 12:35 AM D wrote:
> Hi All,
>
> I am interested in adding (or having) a new function
I would prefer to start with an offer to give someone else access to
maintain the code, rather than shutdown an existing codebase.
If this fork is better, maybe we can get them to merge everything and they
take over?
Another option, we move it to prometheus-community.
On Wed, Feb 26, 2020 at
Yes
On Wed, Feb 19, 2020 at 9:44 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:
> Dear all,
>
> I am hereby calling for a vote on merging
> https://github.com/prometheus/docs/pull/1552 at commit
> de2266c36d8a2ea1f139f97632808e12b354bb76.
>
> References and discussion can be found in
have PRs which are ready to
> merge, but have been sitting there months waiting for a DCO.
>
> Brian
>
>
>>
>> I agree that in *many* cases contributors can write the changelog
>> entry; having the field in the PR template would encourage them to do so
>> pro
ip one. This would be even more difficult with wording.
>
> I agree that in *many* cases contributors can write the changelog entry;
> having the field in the PR template would encourage them to do so
> proactively.
>
> /MR
>
> On Fri, Feb 14, 2020 at 1:12 PM Ben Kochie
DCO is a strawman argument. We're always going to have issues with
submission quality.
I've had very good luck asking for changelog entries on the node_exporter.
On Fri, Feb 14, 2020 at 8:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:
> On Fri, 14 Feb 2020 at 07:10, Frederic
Part of the problem is that we run the builds in serial. We have a lot more
compute capacity in our CircleCI for running more docker tasks in parallel,
but promu doesn't know how to distribute the work.
But I also think we could cut the build step down for PRs. But I think we
should keep the full
82 matches
Mail list logo
