Hi,
I'm setting up a dashboard and receiving data from prometheus through metricbeat, I'm facing problem when it comes to value mapping, in my case for "DoorStatus" i want to map the default integer values in 0 and 1 to display as 0=Unlocked, 1=Locked, similarly for "LockStatus" and for "BranchStatus" I need it as UP/DOWN, but I dont see any value in that field just a "-".
So is there any way we could map the values?
Screenshot is attached for reference.
Thanks in advance
hello @saif.khan ! You should be able to do something like this using painless in your query or creating a runtime field depending on how you are query for this data.
Thanks, Will give it a try!
Just answered a similar question here with an example
@stephenb Thank you, Will give it a try.
@stephenb So I tried the script but it's giving me error " No field found for [cpiPduDoorStatus] in mapping"
My DataStream is "metricbeat-8.3.2*"
Script used:
def status = doc['cpiPduDoorStatus'].value;
if (status != null ) {
if (status == 1 ) {
emit ("open");
return;
}
else {
emit ("closed");
return;
}
}
emit("Unknown");
Please rectify the error for me.
Did you check the field exists in the mapping Data View?
Check the Data View
Or is it
cpiPduDoorStatus.keyword
Thanks for your response,
Earlier i was getting cpiPduDoorStatus & cpiPduDoorStatus.keyword, along with the error "Limit of total fields [1000] has been exceeded" in logs which was fixed by increasing limit to 2000,
For your other question yes the field exists, maybe not in all Document ID's but in most of them,
Attaching a whole screen screenshot for better understanding,
On the left side you can see my discover search results, Add field script in the middle and the data preview on the right.
1- With one of the Document ID's containing the field
2- With Document ID not containing the field
What version stack are you on?
Did you trying saving it and see if it works anyway ... there were some early bugs in that window?
It is complaining that the mapping is not present (they are cached sometimes) especially if you have a really large number of fields
I'm on v8.3.2, I tried to save it but it didnt let me, kept highlighting the error. About the large number of fields, I have 128 fields only.
Show me the mappings for that field
Sure, here it is
"cpiPduDoorStatus": {
"properties": {
"1": {
"properties": {
"12": {
"properties": {
"48": {
"properties": {
"48": {
"properties": {
"48": {
"properties": {
"69": {
"properties": {
"68": {
"properties": {
"51": {
"properties": {
"48": {
"properties": {
"48": {
"properties": {
"70": {
"properties": {
"57": {
"properties": {
"57": {
"properties": {
"69": {
"type": "long"
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
},
"2": {
"properties": {
"12": {
"properties": {
"48": {
"properties": {
"48": {
"properties": {
"48": {
"properties": {
"69": {
"properties": {
"68": {
"properties": {
"51": {
"properties": {
"48": {
"properties": {
"48": {
"properties": {
"70": {
"properties": {
"57": {
"properties": {
"57": {
"properties": {
"69": {
"type": "long"
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
},
I'm not sure if that's intentional or not, but cpiPduDoorStatus that is an object not an actual concrete field so that is why it does not work.
The actual field is which is a long Is that last 69 for example
cpiPduDoorStatus.1.12..........69
All the way to the last number
I got your point, it's totally unintentional actually I'm collecting data from network devices through SNMP using Logstash Snmp input plugin, Just for your reference I'm attaching my logstash-snmp.conf, Honestly it's nothing complex so i dont think the cause for this issue would be here, but I'm sure you can help. 
input {
snmp {
walk => ["1.3.6.1.4.1.30932.1.10.1.2.10","1.3.6.1.4.1.30932.1.10.1.3.110","1.3.6.1.4.1.30932.1.10.1.7.100"]
get => ["1.3.6.1.4.1.30932.1.1.3.8.1","1.3.6.1.4.1.30932.1.1.3.9.1"]
hosts => [{host => "udp:device1-IP/161" community => "public" version => "2c"},{host => "udp:device2-IP/161" community => "public" version => "2c"},{host => "udp:device3-IP/161" community => "public" version => "2c"}]
mib_paths => "/etc/logstash/mibs/CPI-PDU-MIB.dic"
#oid_root_skip => 13
oid_path_length => 15
interval => 30
}
}
filter {
mutate {
rename => {"iso.org.dod.internet.private.enterprises.cpi.products.unity.econnect.branch.cpiPduBranchTable" => "C"}
rename => {"iso.org.dod.internet.private.enterprises.cpi.products.unity.econnect.systeminfo.cpiPduTable" => "9"}
rename => {"iso.org.dod.internet.private.enterprises.cpi.products.unity.econnect.easData.cpiEasTable" => "-"}
rename => {"iso.org.dod.internet.private.enterprises.cpi.products.legacy.metrics.humidity.humidityProbe1" => "Humidity_Probe1"}
rename => {"iso.org.dod.internet.private.enterprises.cpi.products.legacy.metrics.temperature.temperatureProbe1" => "Temperature_Probe1"}
}
}
output {
stdout
{
codec => rubydebug
}
elasticsearch {
action => "index"
hosts => ["https://esIP:9200"]
cacert => "/etc/logstash/certs/http_ca.crt"
index => "snmp"
user => "xxxxxx"
password => "xxxxxxxxx"
}
}
1st I know nothing about SNMP and the logstash plugin etc.. apologies looks like you know more about it thatn me 
2nd You don't actually need to "Fix" anything .. you just need to reference the correct concrete field and it should work.
So in the code.
def status = doc['ccpiPduDoorStatus.1.12.the.correct.numbers.etc......69'].value;
if (status != null ) {
if (status == 1 ) {
emit ("open");
return;
}
else {
emit ("closed");
return;
}
}
emit("Unknown");
the . in json indicate a sub-object / field .. that is all that is happening.
Thanks alot for your support,
I understood your point now, Basically this is another refinement issue I'm trying to fix.
The correct numbers you are referring here are actually the OID's for the pdu fields,
So I have tried using oid_root_skip and oid_path_length function to shorten the extra parameters.
The typical raw output I was receiving was something like iso.org.dod.internet.private.enterprises.cpi.products.unity.econnect.easData.cpiEasTable.cpiPduDoorStatus= (value- 0/1). 1.12...........69 ,
Where the required field is only cpiPduDoorStatus= Value,
unfortunately I'm only able to reduce it to cpiPduDoorStatus= (value- 0/1). 1.12...........69 using oid_path_length hence the issue you rectified above.
Just to mention the issue is only when I'm using WALK, its basically giving the whole path length of the parent tree, sub tree etc.
While using GET I can perfectly rename it, but again not the most efficient way.
Hopefully you or someone else from the team will be able to help me with this, I could open a new topic for this but I feel with the above discussion it gives a better idea of the issue and how it is affecting while in use, rather than me trying to explain it in words.
Once again Thank you for your support.
Hi @saif.khan I am not sure what your question is / what you are asking.
and Again I know just enough about SNMP to be dangerous
The long . name is fine and perfectly acceptable if it works for you
If you want a "Shorter / Easier" Name I can think of some possible approaches
Options...
Simple:
Use a simple field alias to point to the long name See here
Harder:
Fix / change the field names prior to ingest e.g. substitute example . with _ or something, that would require some coding in logstash
I am not sure what issue you are really trying to solve at this point.
Right, I ll look into it.
No issues actually just refinements.
Thanks for the support
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
© 2020. All Rights Reserved - Elasticsearch
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant logo are trademarks of the Apache Software Foundation in the United States and/or other countries.