On that

¹checkmate: Fast Argument Checks for Defensive R Programming

Background

It could be useful for objects returned by promR to extend the existing as.xts and as.ts methods.

Desired behaviour

library(promR)
prom <- Prometheus$new(host = "http://demo.robustperception.io", port = 9090)
# Timestamps can be in rfc3339 or unix format
metrics_instant <- prom$query(query = "go_goroutines", 
                              time = as.POSIXct(Sys.time() - 60))
metrics_instant_xts <- xts::as.xts(metrics_instant)
class(metrics_instant_xts)
# [1] "xts" "zoo"

Current behaviour

xts::as.xts(metrics_instant)

Error in as.POSIXlt.character(x, tz, ...): character string is not in a standard unambiguous format

Side notes

May be worth reflecting whether there is merit in:

• Providing zoo::as.zoo. Properly implemented as.xts method should return an object usable by zoo compatible methods. From ?as.xts documentation:

  (...) The returned object will preserve all relevant attribute/slot data within itself, allowing for temporary conversion to use zoo and xts compatible methods. (...)

• as.ts method is likely, not useful in the current implementation, where metrics objects return data for various categories, as visible in table(metrics_instant$job).

Create a vignette with sample use cases for the available queries.

Seems like formatting function wasn’t applied to this output as it still has X__name__ in column name.

Currently, it seems the value column is being cast as a character type, meaning users have to cast to complex or numeric.

library(promR)
library(ggplot2)
prom <- Prometheus$new(host = "http://demo.robustperception.io", port = 9090)
metrics_instant <- prom$query(query = 'go_goroutines', time = as.POSIXct(Sys.time() - 60))
m <- ggplot(metrics_instant, aes(metrics_instant$job)) + 
  geom_bar(aes(weight=as.complex(metrics_instant$value))) +
  xlab("Prometheus Jobs") +
  ylab("Value")
plot(m)

Ideally this should be handled for the user as the value column will always be a numerical value.

However, some Prometheus metrics will return scientific notation when the value is large enough.

For example:
alertmanager_silences_query_duration_seconds_bucket{le="2.5"} 4.766468e+06

Is there any reason we shouldn't just cast everything to the complex type? Or would it be better to default to numeric unless complex is required? What's your opinion @konradzdeb?

Problem

The when running sample code:

metrics_current <- prom$query(query = "go_goroutines", 
                              time = format(Sys.time(),  "%Y-%m-%dT%H:%M:%SZ"))
# Error in format_metrics_current_data(metrics) : 
#  Assertion on 'x' failed: Must have at least 1 rows, but has 0 rows.
metrics_current <- prom$query(query = "go_goroutines", 
                             time = format(Sys.time() - 10,  "%Y-%m-%dT%H:%M:%SZ"))
 # Error in format_metrics_current_data(metrics) : 
 #  Assertion on 'x' failed: Must have at least 1 rows, but has 0 rows.

for:

Sys.time()
# [1] "2019-04-01 07:22:00 BST"

the data would be produced for Sys.time() - 3600

metrics_current <- prom$query(query = "go_goroutines", 
                               time = format(Sys.time() - 3600,  "%Y-%m-%dT%H:%M:%SZ"))

It's unclear whether:

• there is no data for the period corresponding to 07:22 but there is for an hour earlier (?) Sys.time() - 3600
• the connection failed
• query failed

Suggested resolution

For internet connection

If possible to solve through #11 if not consider running curl::has_internet() before query, return stop

if (!curl::has_internet()) stop("This machine is not connected to the Internet :)")

For query

Shall return something like (?):

The query completed but returned no data....

Potentially related to #11

devtools::check() returns a warning about missing documentation

❯ checking for missing documentation entries ... WARNING
  Undocumented S4 classes:
    ‘Prometheus’
  All user-level objects in a package (including S4 classes and methods)
  should have documentation entries.
  See chapter ‘Writing R documentation files’ in the ‘Writing R
  Extensions’ manual.

Error in metrics <- format_metrics_range_data(metrics) (main.R#85): Assertion on 'x' failed: Must have at least 1 rows, but has 0 rows.

It would be nice though, if it would just work (and return an empty result?).

Currently we have differing column names depending on query, we should really make it more consistent. Mainly the name column name.

e.g.

An instant query results in:

where as range query results in:

tl;dr X__name__ should be name instead

Hi All,

Firstly thanks for taking the time to support this project.

Would there be an appetite to pass basic auth creds? For instance if Prometheus is hosted in Openshift/OKD it will sits behind an auth proxy.

The thinking would be if someone were to pass a username/password then try and authenticate, if these aren't present then don't use them.

Any thoughts?

Thanks

Matt

Consider exporter that exposes following metrics:

tcp_queue{state="LISTEN", dir="rx", addr="0.0.0.0", port="6432"} 0
tcp_queue{state="LISTEN", dir="rx", addr="127.0.0.1", port="5432"} 0

This is what prom$rangeQuery(query = 'tcp_queue', ...)$port returns instead of expected values:

 [1] 12345 12345 12345 12345 12345 12345 12345 12345 12345 12345 12345 12345
[13] 12345 12345

where 12345 actually comes from instance="127.0.0.1:12345"

The current error messages raised when we receive a non-200 status code are very basic.

We should be parsing JSON object returned by Prometheus to enrich our error messages.

httptest offers a dedicated environment for testing functions that wrap APIs. I reckon we should consider this instead of faffing around trying to mock/wrap httr::GET. It seems that a substantial effort was put in that package to facilitate the development of testing and vignette generation. We would, in effect, swap one dependency for another mockery -> httptest. It just feels cleaner to me as it was developed for that purpose and looks like a more mature development.

httptest makes it easy to write tests for code and packages that wrap web APIs. Testing code that communicates with remote servers can otherwise be painful: things like authentication, server state, and network flakiness can make testing seem too costly to bother with. The httptest package enables you to test all of the logic on the R sides of the API in your package without requiring access to the remote service.

FYI @glenn-m

Currently we have few tests around the formatting of the metrics output from Prometheus, this should be improved.

We should also avoid having a reliance on external systems for the tests. Perhaps we can create a data set for use in testing?

test-metrics-format.R

With respect to the object that is returned here:

Is the generated data frame of similar format that is handled by the function that formats metrics for ranges and instant query? If so a potential solution could be to devise one generic function that formats all data frame outputs returned by Prometheus, irrespectively of the query. If you haven’t started on that, I’m happy to progress this (assuming that this is the right approach, of course)