jrock.us VS Telegraf

I used 1.x for my push-monitoring stack at my last job. (For cases where "pull" is practical, I would always use Prometheus. Prometheus also has "push" now, by the way.) They went into 2.0 mode and kind of neglected 1.x, and I kind of forgot about it. At the time, I was most familiar with an internal monitoring system at Google, and I found I couldn't do queries that I expected to be able to do. I even mentioned it on HN and some influx folks told me that what I wanted to do was too weird to support. (It's not. I was collecting byte counters from fiber CPEs, and wanted to have bandwidth charts based on topology tags I stored with the data -- imagine a SQL table like (serial_number text not null, time timestamp not null, locality text not null, bytes_sent int64 not null, bytes_received int64 not null). The problem was that timestamps would not be aligned between records in the same locality group -- I sampled these occasionally throughout the day and not all at the same instant. And, they were counters, not deltas, so the query would have to do the delta across each serial number, and then aggregate across all devices in a locality. Very possible to do, I literally had that chart with the other monitoring system. But not possible with the influx v1 querying, as far as I could tell.)

I set up 2.x for myself recently, and they have really done a lot of work. The OSS offering has most of the features that cloud/enterprise would. It was easy to set up -- they don't have any instructions for installing it in Kubernetes, and haven't updated their Helm charts for 2.x, but it was like 3 minutes to write a manifest (https://github.com/jrockway/jrock.us/tree/master/production/...) myself, which I prefer 99.9% of the time anyway. The new query language is incredibly verbose, but I see the steps that I remember having with Google's internal system, align, delta, aggregate... all possible. (I had to scratch my head a lot, though, to make it work. And I really am not able to reason about what operations it's doing, what's indexed or not indexed, why I ingest my data as rows but process it as columns, etc.) The performance is good, and it worked well for my use case of pushing data from my Intranet of Stuff. Generally I like it and I don't think they are being shady in any way. Definitely considering using it at work for collecting timing information from regular performance tests and CI steps. (To enable my coworkers to make performance improvements and see "according to this dashboard, I made this release 10% faster!")

The reason I picked InfluxDB over TimescaleDB for my personal stuff is because InfluxDB has an API with built-in authentication. I can give each of my devices an API key from their web interface, and I make an HTTP request to write data. Very simple. (They have a client library, but honestly my main target is a Beaglebone, and it doesn't have enough memory to compile their client library. I've never seen "go build" run out of memory, but their client makes that happen. I shouldn't develop on my IoT device, of course, but it's just easier because it has Emacs and gopls, and all the sensors connected to the right bus. Was easier to just manually make the API calls than to cross-compile on my workstation and push the release build to the actual device.) TimescaleDB doesn't have that, because it's just Postgres. So I'd basically have to expose port 5432 to the world, create Postgres users for every device, generate a password, store that somewhere, etc. Then to ingest data, I'd connect to the database, tune my connection pool, retry failed requests manually, etc. Using HTTP gets me all that for free; I can just configure retries in Envoy.

But... SQL queries are a lot easier to figure out than FluxQL queries, and I already have good tools for manipulating raw data in Postgres (DataGrip is my preferred method), so I think I will likely be revisiting TimescaleDB. Honestly, I'd pay for a managed offering right now if they had a button in Google Cloud Console that was "Create Instance and by the way this just gets added to your GCP bill for 10% more than a normal Cloud SQL instance".

Telegraf’s Secretstores Plugin implementation on GitHub

Do you mean Telegraf?

I have two devices; both are connected to a Raspberry Pi using a USB converter as Slave 1 and 2. I want to get some readings using Telegraf software https://github.com/influxdata/telegraf/tree/release-1.26/plugins/inputs/modbus (happy to try any other linux software), but I'm having trouble (I'm seriously confused to be honest) with byte_order, data_type, and input register addresses.

Back when I was using AWS CloudFormation, I found a need to use Troposphere [0] to do some logic that couldn't be done in CloudFormation itself. When I switched to Terraform most of those problems went away since there is even better ways to perform simple programming logic in it.

Maybe there are some use cases where you still need to perform logic outside of Terraform where AsCode could be useful to some people.

I've seen the Starlark configuration language used in other places, such as Telegraf [0], but I think this is an interesting use of it.

[0] https://troposphere.readthedocs.io/en/latest/index.html

[1] https://github.com/influxdata/telegraf/blob/master/plugins/p...

Telegraf agent scraping your Apache logs with the tail input plugin (parsing each entry into desired metrics at the same time), and saving them to a flat file in CSV format with the file output plugin. Then you could have a script parse the CSV file and upload it to MySQL at your desired cadence. Or, you could even have telegraf execute the script for you at your desired batch interval, with the exec output plugin.

I would use telegraf (https://github.com/influxdata/telegraf) to gather the metrics you want from your servers. It has built-in functions to get metrics like disk usage, cpu, etc...

From there I would export those metrics to a grafana+influxdb setup. But honestly this is because that's what I'm used to professionally. There might be simpler solutions around.