Unable to access Grafana UI on Kubernetes

Unable to access Grafana UI on Kubernetes

I have a K8S cluster setup on openstack using the COREOS guide.
I am getting following error while accessing the GRAFANA UI on http://master-ip:8080/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/
Error: ‘dial tcp 172.17.0.5:3000: i/o timeout’
Trying to reach: ‘http://172.17.0.5:3000/’

I can access the InfluxDB UI at the influxdb-nodeip:8083.
I can curl to 172.17.0.5:3000 from within the node.
Steps I followed:

Created the K8S cluster with 1 master and 1 node.
Created namespace
Setup DNS
Confirmed DNS is working using busybox example.
Setup InfluxDB and Grafana.

Grafana container log
2016/04/21 14:53:33 [I] Listen: http://0.0.0.0:3000/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
.Grafana is up and running.
Creating default influxdb datasource…
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 242 100 37 100 205 3274 18143 –:–:– –:–:– –:–:– 18636
HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Set-Cookie: grafana_sess=cd44a6ed54b863df; Path=/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana; HttpOnly
Date: Thu, 21 Apr 2016 14:53:34 GMT
Content-Length: 37

{“id”:1,”message”:”Datasource added”}
Importing default dashboards…
Importing /dashboards/cluster.json …
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 71639 100 49 100 71590 539 769k –:–:– –:–:– –:–:– 776k
HTTP/1.1 100 Continue

Cluster-info
cluster-info
Kubernetes master is running at :8080
Heapster is running at :8080/api/v1/proxy/namespaces/kube-system/services/heapster
KubeDNS is running at :8080/api/v1/proxy/namespaces/kube-system/services/kube-dns
Grafana is running at :8080/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
InfluxDB is running at :8080/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb

version
Client Version: version.Info{Major:”1″, Minor:”1″, GitVersion:”v1.1.8″, GitCommit:”a8af33dc07ee08defa2d503f81e7deea32dd1d3b”, GitTreeState:”clean”}
Server Version: version.Info{Major:”1″, Minor:”1″, GitVersion:”v1.1.8″, GitCommit:”a8af33dc07ee08defa2d503f81e7deea32dd1d3b”, GitTreeState:”clean”}

Node iptables: sudo iptables -n -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
KUBE-PORTALS-CONTAINER all — 0.0.0.0/0 0.0.0.0/0 /* handle ClusterIPs; NOTE: this must be before the NodePort rul es */
DOCKER all — 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
KUBE-NODEPORT-CONTAINER all — 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL /* handle service NodePorts; NOTE : this must be the last rule in the chain */

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
KUBE-PORTALS-HOST all — 0.0.0.0/0 0.0.0.0/0 /* handle ClusterIPs; NOTE: this must be before the NodePort rules */
DOCKER all — 0.0.0.0/0 !127.0.0.0/8 ADDRTYPE match dst-type LOCAL
KUBE-NODEPORT-HOST all — 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL /* handle service NodePorts; NOTE: thi s must be the last rule in the chain */

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all — 172.17.0.0/16 0.0.0.0/0
MASQUERADE tcp — 172.17.0.5 172.17.0.5 tcp dpt:8086
MASQUERADE tcp — 172.17.0.5 172.17.0.5 tcp dpt:8083

Chain DOCKER (2 references)
target prot opt source destination
DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:8086 to:172.17.0.5:8086
DNAT tcp — 0.0.0.0/0 0.0.0.0/0 tcp dpt:8083 to:172.17.0.5:8083

Chain KUBE-NODEPORT-CONTAINER (1 references)
target prot opt source destination

Chain KUBE-NODEPORT-HOST (1 references)
target prot opt source destination

Chain KUBE-PORTALS-CONTAINER (1 references)
target prot opt source destination
REDIRECT tcp — 0.0.0.0/0 10.100.0.1 /* default/kubernetes: */ tcp dpt:443 redir ports 43104
REDIRECT udp — 0.0.0.0/0 10.100.0.10 /* kube-system/kube-dns:dns */ udp dpt:53 redir ports 60423
REDIRECT tcp — 0.0.0.0/0 10.100.0.10 /* kube-system/kube-dns:dns-tcp */ tcp dpt:53 redir ports 35036
REDIRECT tcp — 0.0.0.0/0 10.100.176.182 /* kube-system/monitoring-grafana: */ tcp dpt:80 redir ports 41454
REDIRECT tcp — 0.0.0.0/0 10.100.17.81 /* kube-system/heapster: */ tcp dpt:80 redir ports 40296
REDIRECT tcp — 0.0.0.0/0 10.100.228.184 /* kube-system/monitoring-influxdb:http */ tcp dpt:8083 redir ports 39963
REDIRECT tcp — 0.0.0.0/0 10.100.228.184 /* kube-system/monitoring-influxdb:api */ tcp dpt:8086 redir ports 40214

Chain KUBE-PORTALS-HOST (1 references)
target prot opt source destination
DNAT tcp — 0.0.0.0/0 10.100.0.1 /* default/kubernetes: */ tcp dpt:443 to:10.10.1.84:43104
DNAT udp — 0.0.0.0/0 10.100.0.10 /* kube-system/kube-dns:dns */ udp dpt:53 to:10.10.1.84:60423
DNAT tcp — 0.0.0.0/0 10.100.0.10 /* kube-system/kube-dns:dns-tcp */ tcp dpt:53 to:10.10.1.84:35036
DNAT tcp — 0.0.0.0/0 10.100.176.182 /* kube-system/monitoring-grafana: */ tcp dpt:80 to:10.10.1.84:41454
DNAT tcp — 0.0.0.0/0 10.100.17.81 /* kube-system/heapster: */ tcp dpt:80 to:10.10.1.84:40296
DNAT tcp — 0.0.0.0/0 10.100.228.184 /* kube-system/monitoring-influxdb:http */ tcp dpt:8083 to:10.10.1.84:39963
DNAT tcp — 0.0.0.0/0 10.100.228.184 /* kube-system/monitoring-influxdb:api */ tcp dpt:8086 to:10.10.1.84:40214

describe pod –namespace=kube-system monitoring-influxdb-grafana-v3-grbs1
Name: monitoring-influxdb-grafana-v3-grbs1
Namespace: kube-system
Image(s): gcr.io/google_containers/heapster_influxdb:v0.5,gcr.io/google_containers/heapster_grafana:v2.6.0-2
Node: 10.10.1.84/10.10.1.84
Start Time: Thu, 21 Apr 2016 14:53:31 +0000
Labels: k8s-app=influxGrafana,kubernetes.io/cluster-service=true,version=v3
Status: Running
Reason:
Message:
IP: 172.17.0.5
Replication Controllers: monitoring-influxdb-grafana-v3 (1/1 replicas created)
Containers:
influxdb:
Container ID: docker://4822dc9e98b5b423cdd1ac8fe15cb516f53ff45f48faf05b067765fdb758c96f
Image: gcr.io/google_containers/heapster_influxdb:v0.5
Image ID: docker://eb8e59964b24fd1f565f9c583167864ec003e8ba6cced71f38c0725c4b4246d1
QoS Tier:
memory: Guaranteed
cpu: Guaranteed
Limits:
cpu: 100m
memory: 500Mi
Requests:
cpu: 100m
memory: 500Mi
State: Running
Started: Thu, 21 Apr 2016 14:53:32 +0000
Ready: True
Restart Count: 0
Environment Variables:
grafana:
Container ID: docker://46888bd4a4b0c51ab8f03a17db2dbf5bfe329ef7c389b7422b86344a206b3653
Image: gcr.io/google_containers/heapster_grafana:v2.6.0-2
Image ID: docker://7553afcc1ffd82fe359fe7d69a5d0d7fef3020e45542caeaf95e5623ded41fbb
QoS Tier:
cpu: Guaranteed
memory: Guaranteed
Limits:
cpu: 100m
memory: 100Mi
Requests:
memory: 100Mi
cpu: 100m
State: Running
Started: Thu, 21 Apr 2016 14:53:32 +0000
Ready: True
Restart Count: 0
Environment Variables:
INFLUXDB_SERVICE_URL: http://monitoring-influxdb:8086
GF_AUTH_BASIC_ENABLED: false
GF_AUTH_ANONYMOUS_ENABLED: true
GF_AUTH_ANONYMOUS_ORG_ROLE: Admin
GF_SERVER_ROOT_URL: /api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/
Conditions:
Type Status
Ready True
Volumes:
influxdb-persistent-storage:
Type: EmptyDir (a temporary directory that shares a pod’s lifetime)
Medium:
grafana-persistent-storage:
Type: EmptyDir (a temporary directory that shares a pod’s lifetime)
Medium:
default-token-lacal:
Type: Secret (a secret that should populate this volume)
SecretName: default-token-lacal
Events:
FirstSeen LastSeen Count From SubobjectPath Reason Message
───────── ──────── ───── ──── ───────────── ────── ───────
23m 23m 5 {scheduler } FailedScheduling Failed for reason PodFitsHostPorts and possibly others
22m 22m 1 {kubelet 10.10.1.84} implicitly required container POD Created Created with docker id 97a95bd1f80a
22m 22m 1 {scheduler } Scheduled Successfully assigned monitoring-influxdb-grafana-v3-grbs1 to 10.10.1.84
22m 22m 1 {kubelet 10.10.1.84} implicitly required container POD Pulled Container image “gcr.io/google_containers/pause:0.8.0” already present on machine
22m 22m 1 {kubelet 10.10.1.84} spec.containers{grafana} Pulled Container image “gcr.io/google_containers/heapster_grafana:v2.6.0-2” already present on machine
22m 22m 1 {kubelet 10.10.1.84} spec.containers{grafana} Created Created with docker id 46888bd4a4b0
22m 22m 1 {kubelet 10.10.1.84} spec.containers{grafana} Started Started with docker id 46888bd4a4b0
22m 22m 1 {kubelet 10.10.1.84} spec.containers{influxdb} Pulled Container image “gcr.io/google_containers/heapster_influxdb:v0.5” already present on machine
22m 22m 1 {kubelet 10.10.1.84} implicitly required container POD Started Started with docker id 97a95bd1f80a
22m 22m 1 {kubelet 10.10.1.84} spec.containers{influxdb} Created Created with docker id 4822dc9e98b5
22m 22m 1 {kubelet 10.10.1.84} spec.containers{influxdb} Started Started with docker id 4822dc9e98b5

Don’t know what else to share. I can share other information if required. Please help, I couldn’t find any solution for this.
EDIT
The response from the command as suggested in the answer below:
kubectl attach -it –namespace=kube-system monitoring-influxdb-grafana-v2-c2tj9

J[04/21/16 23:30:19] [INFO] Loading configuration file /config/config.toml

0+———————————————+
0| _____ __ _ _____ ____ |
0| |_ _| / _| | | __ \| _ \ |
0| | | _ __ | |_| |_ ___ _| | | | |_) | |
0| | | | ‘_ \| _| | | | \ \/ / | | | _ < | 0| _| |_| | | | | | | |_| |> <| |__| | |_) | | 0| |_____|_| |_|_| |_|\__,_/_/\_\_____/|____/ | 0+---------------------------------------------+ Thanks

Solutions/Answers:

Solution 1:

To help drill down on what the problem is, I’d recommend seeing if the master is able to reach the pod at all. This’ll help determine whether the issue is in your networking setup as a whole or just with the service routing from the master.

You should be able to verify whether the apiserver can reach the pod by kubectl attach -it --namespace=kube-system monitoring-influxdb-grafana-v3-grbs1 and seeing whether it’s able to connect. If it can connect, then there’s something wrong with the service routing. If it can’t, then the master is having trouble communicating with the node.

References

Is there a way to send data from InfluxDB to Kafka?

Is there a way to send data from InfluxDB to Kafka?

Is there a way to send data from influxDB to kafka? Also, the kafka topic has an avro schema defined. So I wanted to know if there was a way to send data into kafka from InfluxDB keeping this in mind as well.

Solutions/Answers:

Solution 1:

There appears to be a few options for this:

You could also write your own using the InfluxDB API.

References

Query across InfluxDb metrics?

Query across InfluxDb metrics?

I have 3 time-series metrics in an InfluxDb database, akin to:
myservice_processed
myservice_invoked
myservice_error

so to get a time-series set of values, I have a grafana graph that maps:
select sum(value) from myservice_processed where $timeFilter GROUP BY time($interval) fill(null)

…for each of the three values. This gives an idea of how many invocations, successes and failures are occurring every minute. Generally, the sum of processed and error should equal the value of invoked.
Now I want to get a time series value, based upon the above metrics, that gives me the percentage of failures. For example, in any given time interval, I may have 1000 invocations, with 900 processed and 100 errors; I’d like that metric to be 10% for that interval.
For the life of me, I cannot figure out how to do this, and I have begun to suspect it cannot be done, which is mind-boggling to me. Can someone please tell me I’m wrong and show me how to do it?

Solutions/Answers:

Solution 1:

This is currently not possible since Influxdb does not support aggregations function over multiple series right now (influxdb 1.0)

So far Grafana does not support time serie calculations but we do have an ticket for the issue https://github.com/grafana/grafana/issues/3677

Solution 2:

This could be done within InfluxDB by a set of continuous queries.

InfluxDB seems to work on the principle that storage is cheap and unscheduled processor time is expensive. Setting up background continuous calculations that store their results is easy, and it lets a calculation quietly churn in the background. Doing on-the-fly calculations within InfluxDB quickly gets awkward (or impossible, if they span measurements).

Strategy

Every e.g. five minutes, perform a sum of each metric, grouped by time, and insert the sums into a fourth measurement, called myservice_summary.

Instead of having a single field called value, myservice_summary will have several fields; one for invoked calls, one for processed calls, and one for calls with errors. Instead of the default name value, we name the fields something meaningful to the people reading the data.

Note that condensing the data with GROUP BY time(x) (in this example, every five minutes) also reduces your storage overhead, and the client query time (fewer points to retrieve, transmit, and display on the client). It also reduces storage requirements. It’s common in InfluxDB to use at least two retention policies: raw data gets trimmed within a short time (e.g. 30 days), and the condensed and processed data can remain for much longer (e.g. months, years, …)

Of course, picking too large a GROUP BY time() interval means coarse resolution that might be bad for fault-finding. e.g. It’s not much use having GROUP BY time(1d) when you need to know in which hour to start looking for a particular change.

An optimal time grouping window balances meaningful detection of when issues start / stop with speed of client response and storage load. Finding this optimal value is left as an exercise. 🙂

Example

Note that when using the CLI, for each of the three continuous queries below, everything from CREATE CONTINUOUS QUERY to END might need to be on one line to avoid syntax errors. I’ve put line breaks in only to improve readability.

The square brackets [ ] indicate optional parameters. The brackets themselves are not to be literally included.

In this case, you would use the extra tag keys to choose which keys are significant and should be in the new measurement.

CREATE CONTINUOUS QUERY myservice_processed_sum_5m ON your_db_name
BEGIN
    SELECT sum(value) AS processed_sum_5m 
    INTO myservice_summary 
    FROM myservice_processed GROUP BY time(5m)[, other_tag_keys e.g. vendor_id]
END 

CREATE CONTINUOUS QUERY myservice_invoked_sum_5m ON your_db_name
BEGIN
    SELECT sum(value) AS invoked_sum_5m 
    INTO myservice_summary 
    FROM myservice_invoked GROUP BY time(5m)[, other_tag_keys e.g. vendor_id]
END 

CREATE CONTINUOUS QUERY myservice_error_sum ON your_db_name
BEGIN
    SELECT sum(value) AS error_sum_5m 
    INTO myservice_summary 
    FROM myservice_error GROUP BY time(5m)[, other_tag_keys e.g. vendor_id]
END

So now we have a new measurement, called myservice_summary, with three fields: processed_sum_5m, invoked_sum_5m, and error_sum_5m (assuming that 5-minute summaries are what you want).

From there, a query for the past 24h of fail percentage would be:

SELECT (error_sum_5m / invoked_sum_5m) * 100.0 
    AS error_pct_5m
    FROM myservice_summary
    WHERE time > now() - 1d
    [GROUP BY other_tags e.g. vendor_id]

Or in a more tabular format:

SELECT [vendor_id, etc, ](error_sum_5m / invoked_sum_5m) * 100.0 
    AS error_pct_5m
    FROM myservice_summary
    WHERE time > now() - 1d

Using the results stored in myservice_summary in another CQ is possible, but I’m not 100% sure about avoiding race conditions, i.e. what if the CQ that depends on myservice_summary executes before a query that populates that measurement?

Hope that helps.

Solution 3:

InfluxDB lacks the analytics constructs to do that kind of things. If you want to stick with influxdb you’ll have to implement that in an external layer and feed the data back into influx.

References

InfluxDb top X offenders

InfluxDb top X offenders

I have an InfluxDb time series database which I am storing a metric called api_calls. This metric has two pertinent measurements, call_invoked and call_failed. Each measurement also has a tag with a vendor id associated with it.
Every minute, I have a service that collates the number of times I invoked call_invoked (fired when I start the API call) and call_failed (fired when I get an error message from the API call) and stores them into an InfluxDb. So basically, every minute I get a record (per tag, as I understand it) in the InfluxDb “table” (for lack of a better term) that has these two values associated with it.
I have been scratching my head trying to figure out how to show the top ten vendor id’s with the largest percentage of API failures.
How can I do this? I have a strong SQL background but everything I’ve tried has either not worked at all or definitely not worked correctly.

Solutions/Answers:

Solution 1:

I’ve made some guesses about your schema, and built up a solution using the CLI. I’m using InfluxDB v1.0.2 here.

Note that TOP() only became a working function around January 2016.

If your version of InfluxDB is older than this, the following won’t work.

First, some sample data:

CREATE DATABASE foo
USE foo
PRECISION rfc3339

INSERT api_calls,vendor_id=1 call_invoked=3i,call_failed=3i 1483228860000000000
INSERT api_calls,vendor_id=2 call_invoked=3i,call_failed=8i 1483228860000000000
INSERT api_calls,vendor_id=3 call_invoked=3i,call_failed=5i 1483228860000000000
INSERT api_calls,vendor_id=4 call_invoked=3i,call_failed=9i 1483228860000000000
INSERT api_calls,vendor_id=5 call_invoked=3i,call_failed=10i 1483228860000000000
INSERT api_calls,vendor_id=6 call_invoked=3i,call_failed=1i 1483228860000000000
INSERT api_calls,vendor_id=7 call_invoked=3i,call_failed=6i 1483228860000000000
INSERT api_calls,vendor_id=8 call_invoked=3i,call_failed=9i 1483228860000000000
INSERT api_calls,vendor_id=9 call_invoked=3i,call_failed=6i 1483228860000000000
INSERT api_calls,vendor_id=10 call_invoked=3i,call_failed=5i 1483228860000000000

Then run the following query. Note that the WHERE time > x AND time < y clause could be replaced with something like WHERE time > now() - 1h.

SELECT TOP(call_failed,3), vendor_id FROM api_calls WHERE time > '2017-01-01T00:00:00Z' AND time < '2017-01-01T00:05:00Z' GROUP BY time(1m)

Which gives a result of:

name: api_calls
---------------
time                    top     vendor_id
2017-01-01T00:00:00Z
2017-01-01T00:01:00Z    10      5
2017-01-01T00:01:00Z    9       4
2017-01-01T00:01:00Z    9       8
2017-01-01T00:02:00Z
2017-01-01T00:03:00Z
2017-01-01T00:04:00Z

Note that every minute that has no data returns one row, but where there is data, there are 3 rows returned.

If we tell the CLI we want to peek at the JSON, we can type format json, and when we repeat that same query we get this:

{"results":[{"series":[{"name":"api_calls","columns":["time","top","vendor_id"],"values":[["2017-01-01T00:00:00Z",null,null],["2017-01-01T00:01:00Z",10,"5"],["2017-01-01T00:01:00Z",9,"4"],["2017-01-01T00:01:00Z",9,"8"],["2017-01-01T00:02:00Z",null,null],["2017-01-01T00:03:00Z",null,null],["2017-01-01T00:04:00Z",null,null]]}]}]}

Does that help?

Edit – Re-worked for percentage.

Apologies – I noticed you were looking for percentage, not Top X count.

In InfluxDB, that’s two problems: the first is how to generate the percentages.

A note about nesting operators in functions: InfluxDB does not yet generally guarantee that nesting functions or operators within function arguments will work. Some do, many don’t. Of importance here: TOP() only allows field keys or tags as arguments, and not operations on tags (e.g. call_failed / total_calls). You’ll need to perform an extra query to generate the percentages, and you’ll have to store them. You can either calculate them on the “raw”, minute-by-minute values:

SELECT (call_failed / (call_failed + call_invoked)) AS pct_fail INTO api_calls FROM api_calls GROUP BY vendor_id

(GROUP BY time is implicit: re-run that query from the CLI without the INTO clause to see how).

Or you can summarize each e.g. hour:

SELECT (sum(call_failed) / (sum(call_failed) + sum(call_invoked))) AS pct_fail INTO api_calls_hourly FROM api_calls GROUP BY time(1h), vendor_id

That can be done as a one-off for existing data. For any newly arriving data, a continuous query can be used:

CREATE CONTINUOUS QUERY fail_pct_calc ON foo BEGIN SELECT (sum(call_failed) / (sum(call_failed) + sum(call_invoked))) AS pct_fail INTO api_calls_summary FROM api_calls GROUP BY time(1h), vendor_id END

(continuous queries require a GROUP BY time() clause).

There’s no technical requirement to push Continuous Query results into a new measurement – you could SELECT the calculation results back INTO api_calls, for example. But putting the raw data and the summary results in the same measurement leads to query results that have a lot of nulls. It’s often tidier in InfluxDB to push the results to a new measurement.

From there, use TOP() as before:

Edited – fixed ‘FROM’ measurement

SELECT TOP(pct_fail,3), vendor_id FROM api_calls_summary WHERE time > '2017-01-01T00:00:00Z' AND time < '2017-01-01T00:05:00Z' GROUP BY time(1m)

References

How to send data to influxdb via post call without using curl?

How to send data to influxdb via post call without using curl?

i am new to influxdb and i was trying to add data to influx db . I found on the documentation page that it can be done using curl.
curl -i -XPOST ‘http://localhost:8086/write?db=mydb’ –data-binary ‘cpu_load_short,host=server01,region=us-west value=0.64 1434055562000000000’

but i want to hit it from the browser and be able to insert data to influxdb.
For select query :
http://localhost:8086/query?db=mydb&q=select * from temperature

this is a url which can be used to get data from influxdb. Is there a similar way to insert data to influxdb.
I tried creating url from curl but wasn’t successful.

Solutions/Answers:

Solution 1:

little bit late but:

you should call REST via POST

url: http://localhost:8086/write?db=mydb
type :POST
body: measurement,value=123 thetime=1502474399000

References

Cannot connect from python to influxdb when running in docker

Cannot connect from python to influxdb when running in docker

Title is not entirely accurate, I’m open for suggestions!
You can find a full MCVE here: https://github.com/timstoop/20170614-python-docker-influxdb-problem
Tested with:

docker-engine 17.05.0~ce-0~ubuntu-xenial
docker-compose version 1.13.0, build 1719ceb

So the docker-compose starts an influxdb and a small python3 app. The only thing the app does is try to connect to influxdb, run a command and if that fails, wait 5 seconds and try again. If I run docker-compose up on this code, the app will never connect, it keeps retrying. These are the log lines it outputs:
app_1 | 2017-06-14 18:57:36.892955 ticker Trying InfluxDB connection…
app_1 | 2017-06-14 18:57:36.892977 ticker Influx host: ‘influxdb’
app_1 | 2017-06-14 18:57:36.892984 ticker Influx port: 8086
app_1 | 2017-06-14 18:57:36.935112 ticker No InfluxDB connection yet. Waiting 5 seconds and retrying.

However, if I open a shell in that specific container using docker exec -ti /bin/sh, the following works fine:
/ # python3 -u
Python 3.6.1 (default, Jun 8 2017, 21:50:56)
[GCC 6.3.0] on linux
Type “help”, “copyright”, “credits” or “license” for more information.
>>> from influxdb import InfluxDBClient
>>> ci = InfluxDBClient(host=’influxdb’)
>>> ci.get_list_database()
[{‘name’: ‘_internal’}]
>>>

I’m sure I’m overlooking something silly, but I’m unable to explain why the app.py won’t make a connection. And thus, I’m unable to fix that connection. Any advise here would be greatly appreciated.
My code, for reference, follows below.
app.py:
#!/usr/bin/env python
from influxdb import InfluxDBClient
import datetime
import sys
import time
import os
import requests

def output(msg):
# Convenience function to always show a correct output
now = datetime.datetime.now()
print(“%s ticker %s” % (now, msg))

if __name__ == ‘__main__’:
# Gather our settings
influx_host = os.getenv(‘INFLUX_HOST’, ‘localhost’)
influx_port = os.getenv(‘INFLUX_PORT’, ‘8086’)
influx_user = os.getenv(‘INFLUX_USER’, ‘root’)
influx_pass = os.getenv(‘INFLUX_PASS’, ‘root’)
# Create our connections
# Check to make sure we can create a connection
got_if_connection = False
while not got_if_connection:
output(‘Trying InfluxDB connection…’)
output(“Influx host: %s” % influx_host)
output(“Influx port: %s” % influx_port)
influx_client = InfluxDBClient(host=influx_host, port=influx_port,
username=influx_user,
password=influx_pass)
try:
influx_client.get_list_database()
except requests.exceptions.ConnectionError:
output(‘No InfluxDB connection yet. Waiting 5 seconds and ‘+
‘retrying.’)
time.sleep(5)
else:
got_if_connection = True

Dockerfile:
FROM python:alpine3.6
MAINTAINER Tim Stoop

# Copy the script in
COPY app.py /app.py
COPY requirements.txt /requirements.txt

# Install dependencies
RUN pip install -r /requirements.txt

CMD [“python3”, “-u”, “/app.py”]

docker-compose.yml:
version: ‘2’
services:
influxdb:
image: “influxdb:alpine”
ports:
– “8086:8086”
app:
build: .
links:
– influxdb
environment:
– INFLUX_HOST=’influxdb’

Please let me know if you need any additional information!

Solutions/Answers:

Solution 1:

Remove quotes from docker-compose.yml file in environment section.

environment:
  - INFLUX_HOST=influxdb

References

Can we set the timezone for influxdb.Chronograf?

Can we set the timezone for influxdb.Chronograf?

I’m currently using chronograf to view my point data in influxdb.
At first the queried results in chronograf seem abnormal to me but I have later worked out the issue to be at timezone differences.
So influxdb could only store data in UTC timezone but chronograf is using my local machine’s timezone to display the data.
Example:
In influxdb I have a point sitting at 7PM on a particular day but when I tried to look it up in chronograf, it is saying timestamp for the same point is on 5PM.
Question:
Is there a way for me to set the default timezone for my chronograf? This is so that it will not try to tamper my data and be showing the original timestamp at UTC?

Solutions/Answers:

Solution 1:

Short answer: It is not possible to display data in UTC in Chronograf 1.3 yet.

Chronograf by default offset influxdb‘s UTC data to whatever your local browser’s time is.

I have raised a github issue to the Chronograf team and hopefully it will support displaying data in UTC soon.

See: https://github.com/influxdata/chronograf/issues/1960

Reference:

https://community.influxdata.com/t/chronograf-set-to-use-local-or-set-timezone/947

https://github.com/influxdata/chronograf/issues/1960

Solution 2:

Install this add-on/extension for Chrome/Chromium
https://chrome.google.com/webstore/detail/change-timezone-time-shif/nbofeaabhknfdcpoddmfckpokmncimpj?hl=en

Install this add-on/extension for Firefox
https://addons.mozilla.org/en-US/firefox/addon/change-timezone-time-shift/

References

influxdb data/table be downloaded as csv file?

influxdb data/table be downloaded as csv file?

Influxdb is a time series database which stores data and its attributes in the tables, commonly known as measurements.
Can the tables in databases of influxdb be fetched to local system in csv format?

Solutions/Answers:

Solution 1:

In CLI following command can be used to download tables on the local system:

influx -database 'database_name' -execute 'SELECT * FROM table_name' -format csv > test.csv

Solution 2:

Using CLI tool influx you can set csv output format for results:

influx -host your_host -port 8086 -database 'your_db' -execute 'select * from your_metric' -format 'csv'

-host and -port options can be omitted if command is run on local InfluxDB host.
There is also useful -precision option to set format of timestamp.

Solution 3:

Alternatively, you can use jq to convert the JSON output to CSV as follows, which also allows you to get RFC3339 formatted timestamps:

jq -r "(.results[0].series[0].columns), (.results[0].series[0].values[]) | @csv"

which gives the output

"time","ppm","T"
"2019-01-17T19:45:00Z",864.5,18.54
"2019-01-17T19:50:00Z",861.4,18.545
"2019-01-17T19:55:00Z",866.2,18.5
"2019-01-17T20:00:00Z",863.9,18.47

and works because:

  • (.results[0].series[0].columns) gets the column names as array
  • , concatenates the output
  • (.results[0].series[0].values[]) gets the data values as array
  • | @csv uses the jq csv formatter
  • -r is used to get raw output

Further resources:

References

Subtract two queries results

Subtract two queries results

Cannot find per the docs, and there is an old issue related to this.
It is possible to subtract the results of 2 queries?
Something like this in SQL:
(SELECT COUNT(*) FROM test – (SELECT COUNT(*) FROM test WHERE …)

Solutions/Answers:

Solution 1:

As far as I know, currently it is not possible (at least not with InfluxQL).

It should, however, be possible with their new query language called Flux (as of InfluxDB1.7)

https://docs.influxdata.com/flux/v0.24/introduction/getting-started/

References

Configuring timezones in InfluxDB

Configuring timezones in InfluxDB

I am experimenting with InfluxDB for timeseries datastore solution, and having an issue with using InfluxDB with different timezones.
Essentially, I am writing all data points into InfluxDB with UTC timestamps, but in the queries it would be very convenient (especially for testing) to specify timestamp ranges using the local timezone of the server.
Does anybody know how to achieve this in InfluxDB?

Solutions/Answers:

Solution 1:

You can compute timezone before or after query to Influxdb by your side, another solutions I don’t see. And btw, use everywhere utc timezone it’s really good decision, and compute to time zone do you need only in last point.

Solution 2:

I living in the other end of the pacific ocean And I using python to put data into influxdb. Once,I was so desperate for the answer of your question.I gave up searching cuz the official did not provide the way to achieve this.
So when I putting data into influxdb,I will decrease my timestamp by 28800. 🙂
and when I need querying, I will do some compensation work like:

def fab_querytime(intime):
    if isinstance(intime,basestring) and len(intime) == 12:
    # my query time args like 201804061200
        _t = arrow.get(intime,'YYYYMMDDHHmm')
        _t = _t.replace(hours=-8)
        return fab_querytime(_t)
    if isinstance(intime,arrow.arrow.Arrow):
       _str = intime.format('YYYY-MM-DDTHH:mm:ss') + '.000Z'
        return str(_str)

References