I return with my doubts about elasticsearch.
I've been doing more testing and I'm almost done learning about ELK.
But I have a little problem. By creating a pipeline and outputting the elasticsearch cluster as follows:
output {
elasticsearch {
hosts => [ "IP:9200", "IP:9200", "IP:9200" ]
manage_template => false
index => "example-%{+yyyy.MM.dd}"
}
}
It does not correctly create the date. I have followed the indications of the documentation as it says: https://www.elastic.co/guide/en/logstash/current/plugins-outputs-elasticsearch.html#plugins-outputs-elasticsearch-index
The above code creates the index: example-
Instead if I leave the default by unchecking the fields manage_template and index it create the index with the format correct: logstash-2020.08.17-000001
So I don't really know what I'm failing at. If it is a documentation issue or some other formatting error.
Another detail is that I have seen some examples from 2018 with the following format: index => "%{[#metadata][beat]}-%{+YYYY.MM.dd}". And reviewing the same previous link about the elasticsearch output plugin means creating different indexes, but I think it refers more to separating indexes according to a production or development space more than creating different indexes according to a date.
After a couple of days I have noticed that I changed the default name of the field #timestamp
Now it works correctly. Thank you
Related
Small part of my CSV log:
TAGS
contentms:Drupal;contentms.ver:7.1.8;vuln:rce;cve:CVE-2018-0111;
cve:CVE-2014-0160;vuln:Heartbleed;
contentms.ver:4.1.6;contentms:WordPress;tag:backdoor
tag:energia;
Idea is that I know nothing of the keys and values other than the format
key:value;key:value;key:value;key:value; etc
I just create an pattern with logstash plugin "kv"
kv {
source => "TAGS"
field_split => ";"
value_split => ":"
target => "TAGS"
}
I've been trying to get my data into Elastic for Kibana and some of it goes through. But for example keys contentms: and contentms.ver: don't get read. Also keys that do - only one value is searchable in Kibana. For example key cve: is seen on mutliple lines mutliple times in my log with different values but only this value is indexed cve:CVE-2014-0160 same problem for tag: and vuln: keys.
I've seen some similar problems and solutions with ruby, but any solutions with just kv? or change my log format around a bit?
I can't test it right now, but notice that you have both "contentms" (a string) and "contentms.ver", which probably looks to elasticsearch like a nested field ([contentms][ver]), but "contentms" was already defined as a string, so you can't nest beneath it.
After the cvs filter, try renaming "contentms" to "[contentms][name]", which would then be a peer to "[contentms][ver]".
You'd need to start with a new index to create this new mapping.
I have a hostname field that's coming in via filebeat to my logstash instance is getting passed to ElasticSearch where it's being treated as an analyzed field. That's causing issues, because the field itself needs to be reported on in it's totality.
Example: Knowing how many requests come to "prd-awshst-x-01" rather than splitting those out into prd, awshst, x, 01.
Does anyone have a lightweight way of doing this that can be used with visualizations?
Thanks,
We have to update mapping from analyzed to not_analyzed for specific field.
PUT/ mapping url/
{
property:{
field:{
text:"not_analyzed"
}
}
}
After updating the property please check is it reflected in mapping using GET method on mapping url.
Based on the title of your post, you already know that you need to change the mapping of the field to not_analyzed.
You should setup a template so that future indexes contain this mapping.
If you want to keep the existing data, you'll have to reindex it into a new index with the new mapping.
If you're using the default logstash template, it might be creating you a not_analyzed ".raw" field that you can use in visualizations in kibana.
The index template that is provided with Filebeat configures the hostname field as not_analyzed.
You should manually install the index template provided with Filebeat and then configure Logstash to write data to the Filebeat index as described in the docs.
This is what the elasticsearch output would look like. If you are processing other data through Logstash, then you might want to add a conditional around this output so that only beat events are sent via this output.
output {
elasticsearch {
hosts => "localhost:9200"
manage_template => false
index => "%{[#metadata][beat]}-%{+YYYY.MM.dd}"
document_type => "%{[#metadata][type]}"
}
}
I am trying to follow the example https://www.digitalocean.com/community/tutorials/how-to-install-elasticsearch-logstash-and-kibana-elk-stack-on-centos-7
But the index name set by 30-elasticsearch-output.conf is not being resolved. In the example 30-elasticsearch-output.conf file:
index => "%{[#metadata][beat]}-%{+YYYY.MM.dd}"
In my case, the result elasticsearch index name is:
"%{[#metadata][beat]}-2016.09.07"
Only the date portion of the index name is set correctly.
What is responsible for setting the metadata value? I must have missed something in following the example.
This is related to a question asked earlier: ELK not passing metadata from filebeat into logstash
You can create index like this
index => "%{[beat][name]}-%{+YYYY.MM.dd}"
This would work definitely.
I intend to have an ELK stack setup where daily JSON inputs get stored in log files created, one for each date. My logstash shall listen to the input via these logs and store it to Elasticsearch at an index corresponding to the date of the log file entry.
My logstash-output.conf goes something like:
output {
elasticsearch {
host => localhost
cluster => "elasticsearch_prod"
index => "test"
}
}
Thus, as for now, all the inputs to logstash get stored at index test of elasticsearch. What I want is that an entry to logstash occurring on say, 2015.11.19, which gets stored in logfile named logstash-2015.11.19.log, must be correspondingly stored at an index test-2015.11.19.
How should I edit my logstash configuration file to enable this ?
Answer because the comment can't be formatted and it looks awful.
Your filename ( I assume you use a file input ) is stored in your path variable as such:
file {
path => "/logs/**/*my_log_file*.log"
}
type => "myType"
}
This variable is accessible throughout your whole configuration, so what you can do is use a regex filter to parse your date out of the path, for example using grok, you could do something like that (look out: Pseudocode)
if [type] == "myType" {
grok {
match => {
"path" => "%{MY_DATE_PATTERN:myTimeStampVar}"
}
}
}
With this you now have your variable in "myTimeStampVar" and you can use it in your output:
elasticsearch {
host => "127.0.0.1"
cluster => "logstash"
index => "events-%{myTimeStampVar}"
}
Having said all this, I am not quite sure why you need this? I think it is better to have ES do the job for you. It will know the timestamp of your log and index it accordingly so you have easy access to it. However, the setup above should work for you, I used a very similar approach to parse out a client name and create sub-indexes on a per-client bases, for example: myIndex-%{client}-%{+YYYY.MM.dd}
Hope this helps,
Artur
Edit: I did some digging because I suspect that you are worried your logs get put in the wrong index because they are parsed at the wrong time? If this is correct, the solution is not to parse the index out of the log file, but to parse the timestamp out of each log.
I assume each log line for you has a timestamp. Logstash will create an #timestamp field which is the current date. So this would be not equal to the index. However, the correct way to solve this, is to mutate the #timestamp field and instead use the timestamp in your log line (the parsed one). That way logstash will have the correct index and put it there.
I'm trying to set up an elk dashboard to see some numbers like total bytes, avg load time, etc. I'm forcing some conversions in logstash to make sure these fields aren't strings
convert => [ "bytes", "integer" ]
convert => [ "seconds", "float" ]
convert => [ "milliseconds", "integer" ]
Those Logstash conversions are working. See this excerpt from my logstash.log. Statuscode is a string, bytes, ... are numbers
"http_statuscode" => "200",
"bytes" => 2731,
"seconds" => 0.0,
"milliseconds" => 9059,
But when I try to build my dashboard with avg, min, max and total bytes for instance elasticsearch logs this:
Facet [stats]: field [bytes] isn't a number field, but a string
Am I missing some kind of conversion or something? Anybody already expierenced this behavior?
Thanks gus yand regards. Sebastian
One possible issue is that the mapping for fields in an index is set when the first document is inserted in the index. Changing the mapping will not update any old documents in the index, nor affect any new documents that are inserted into that index.
If you're in development, the easiest thing is to drop the index (thus deleting your earlier data). Any new documents would then use your new mapping.
If you can't toss the old data, you can wait for tomorrow, when you'll get a new index.
If necessary, you can also rebuild the index, but I've always felt it to be a pain.
One other possibility is that you have the same field name with different mappings in different types in the same index. [ repeat that a few times and it will make sense ]. Field [foo] must have the same mapping definition in each type of the same index.
I recently solved this problem (I mean use bytes or request time as numbers in Kibana, I use v4 beta 3 and you ?). The three following points might help you :
How do you parse your log ? Using Grok filter ? If yes, you can try matching your logs with the following patterns %{INT:bytes:int} instead of using the convert filter.
Did you "reload field list" (yellow button) in Kibana 4 (settings->indices) after you've done your changes ?
If you have old indexes in your ES cluster, did you correctly remove these indexes ? If not, you might have some conflicts between old types and new ones.
Hope it will help.