-
Notifications
You must be signed in to change notification settings - Fork 580
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Where to find influxdb.conf ? #141
Comments
There is no
I'm not too familiar with influxdb, you could try putting in your own config. Directory you're looking for is |
Slyke is spot on - use influxdb.env. But I thought I would expand on Slyke's answer a bit because I'm prety sure putting an influxdb.conf into ~/IOTstack/volumes/influxdb/data won't work. That's because (from the docker-compose.yml file):
The "data" directory ouside the container maps to "/var/lib/influxdb" inside the container. Inside the container, influxdb.conf is in:
and those are not the same directory. I hope that makes sense. If you really want to find influxdb.conf:
You can edit influxdb.conf if you wish. Then, when you restart the container, those changes will be applied. The problem comes later when Docker next rebuilds the container from the image. Anything you have done inside the old container will be lost and you will wind up having to re-do your changes. That's a maintenance hassle you probably don't need. As Slyke said, the recommended approach in the Docker context is editing ~/IOTstack/services/influxdb/influxdb.env and the earlier reply contains a listing of that file. Ignore the "#" characters and notice the pattern where each line begins with "INFLUXDB_". Now, go to the InfluxDB documentation. That link takes you part way down the page, which is intentional. The first entry under "Global Settings" is:
If you were editing influxdb.conf then you would use that syntax. The documentation is also telling you that "false" is the default value so you will only ever need to implement this setting if you want to change it to "true". When you are working in a Docker environment, you need to keep reading a little bit further down until you find:
That tells you that, if you are editing influxdb.env then the syntax you will need is:
All of the Influx options follow that same pattern:
Once you have made a change and saved influxdb.env, you just:
Docker-compose will notice that the influxdb.env has changed and you will see:
How can you check that a change made in influxdb.env gets through to Influx? Well, that can be tricky. One thing you can't do is go into the container and list the contents of influxdb.conf because it doesn't work that way. Environment variables are passed directly. There is no preliminary step where they get mapped into influxdb.conf. Scroll to the near the top of the InfluxDB documentation page and read the "Environment variables" section. This tells you that an option set by an enviroment variable will always override anything in the influxdb.conf. You can confirm that a setting in influxdb.env is getting into the container. For example, assuming influxdb.env contains this line:
then you could check that it is being passed into the container like this:
You can also ask Influx to show you its settings via "show diagnostics". I am not sure whether every option shows up but it is a good place to start. In the case of "reporting disabled" it shows up:
Anyway, while you might want to go into the container and edit influxdb.conf during testing, it's really just as easy to use influxdb.env. |
Going that way, as supposed, I got :
But, it through ..
It seems FLUX isn't working. |
I don't use Telegraf so I can't really comment on that part. Sorry. However, when I see an error message like that one, I will suspect the process generating the query (ie Telegraf) rather than the database engine (Influx). If I got an error like that and wanted to confirm that Influx was working, I would start by connecting to the Raspberry Pi via ssh. The next step is to get into the Influx Command-Line Interface. Graham has a service script at:
but I prefer a scheme of aliases in my .profile
The last line is the most-relevant. I just type:
Whether you use Graham's script, or an alias like I do, or even by just typing the entire "docker exec" command, you wind up in the CLI:
Next, check that your database(s) exist. These are mine:
Your list will be different (obviously) but you should at least see "_internal" along with the databases you have created.
Pick one of your databases:
and then ask what series exist within your chosen database:
Now run a dumb query against one of those:
All up, those steps demonstrate:
I can also replicate your error message by typing a mal-formed query:
That takes me back to my original hypothesis that it's more likely to be the process generating the query (in this case, me, typing bad queries at the CLI) than Influx. Does that help?
|
Paraphraser , Thank you to that long and detailed response. I was trying to use FLUX, a new influxdb feature Otherwise, I think my InfluxDB and influx CLI are working properly as you can see below. `pi@raspberrypi:~/IOTstack/services/influxdb $ ./terminal.sh to create a db: CREATE DATABASE myname to exit type: EXIT Connected to http://localhost:8086 version 1.7.9
_internal
` In case you haven't noticed, I'm pretty beginner, so forgive me if I don't understand straight away what you try to explain. |
I must admit to never having heard of FLUX. I followed the link you provided (thanks) and read through the page but my initial take was that I could not quite see the point. But that’s probably just the natural reaction of someone who has spent much of the last 30 years writing and teaching SQL. It’s probably like everything else in IT - once you have a use case of your own you immediately see the point and it immediately becomes a brilliant idea. In looking at the overall pattern, though, there must be an engine that parses FLUX code and either converts it to Influx’s idea of SQL or bypasses any SQL interface to interact directly with the database. Because the example FLUX statements begin with “from” and it’s clearly the SQL parser that is grizzling about “from” (else it wouldn’t be complaining about not having seen a SELECT etc), it probably follows that you need to invoke a different parser environment. This would seem to be the clue:
I just did a quick test. Assuming you have my “influx” alias installed, this gets the job done:
After that I got a bit lost but I did figure out that a Control+D gets you out of the REPL. |
Hi Paraphraser . it seems I was giving -type=FLUX instead of -type=flux, so I get the previous error.
Checking my config.env gives me : You can see I have the "INFLUXDB_FLUX_ENABLED=true" in my config.env file, but still the error ! |
I think the basic problem is that you are using the wrong key in influxdb.env. I think the key should be:
How did I reach that conclusion? I agree that this is not immediately obvious but there is a clue in the documentation:
When you look through Influx's various "this setting = this environment variable" combinations, there is an implicit rule pattern which is:
Applying those rules gets:
I put this to the test. First, WITHOUT that key added to influxdb.env:
That's close to the error in your output. Next, WITH that key added to influxdb.env and the container restarted:
While the second result still returns an error, at least it's a different error, and it's no longer whinging about the Flux query service being disabled. I'd call that progress - yes? |
I thought it might help if I wrote a gist explaining the how-to of setting up some useful aliases. |
Hi Paraphraser. By the way. May I ask you some more question as you seem to be a database "killer" ? I'm learning database stuff for a near future use that I think it would be useful and practical, but I'm not 100% sure that's the right solution. May I querry my question to you ? Maybe in another post or another place not to disturb that one. |
I sent an email to the address on your profile page. |
Hi.
Where to find influxdb.conf ?
The text was updated successfully, but these errors were encountered: