Hi @Derson, Thank you for the nice and detailed explanation and the test results. I cannot think of anything else to say. I agree with you that may be a bug, it seems better to open a support case for this issue.   

Well... Splunk sometimes does some unintuitive casts between number and string and it's just how it is, I think although so far I've only encountered the opposite situations - the need to explicitly call tonumber() because the field was a string even though it looked like a number. Typing in Splunk isn't that strict (maybe except for datamodels) so I think you just have to get used to it. BTW, you can use typeof() to see the type of a field.

As @scelikok said, your description is a bit vague and without a sample (anonymized if needed - we don't need your internal secrets ;-)) of your data and description of what data you want to get from that it's pretty much impossible to help you because we have no idea what we're talking about.

OK. Maybe you misunderstand how Splunk works. You don't "connect splunk to a linux server". You install UF on a server and (and that might be one of the parts you're missing) you're making it send events to Splunk. So, did you verify any of those things I asked you earlier?

Hi @pranay03, Since your otel collector is already installed without start_at=beginning parameter, you should remove otel , delete checkpoint files on your nodes under "/var/addon/splunk/otel_pos/" folder, and install otel again.. This should make otel to re-read all files. 

Hi @Anurag101, It is not possible to help without knowing your data. Also, the solution depends on whether data is extracted or not.  If you can show some sample anonymized events, we can help by sample query.

Hey @scelikok,  Thanks for jumping in to look at this.  I agree that part of the problem is the typing here because it only returns the wrong lookup uID values for secondUID values that could be reasonably interpreted as numbers. And maybe this comes down to poor error handling.  I wouldn't be satisfied just writing this off to a typing issue though for multiple reasons: First (opaque), this would be completely opaque to the end user.  Maybe you have enough experience to tell me, but if it is a typing issue, then the typeof command does not return the actual types of the variables. I have to believe it returns what Splunk expects it would be. For instance in the search below, the last |like command does not remove any results.  | inputlookup kvstore_560k_lines_long max=15000 | stats count by secondUID | where count=1 AND match(secondUID, "^\d+$") | head 4000 | eval initialType=typeof(secondUID) | eval secondUID=tostring(secondUID) ```this line causes the search to return different results``` | eval subsiquentType=typeof(secondUID) | where like(initialType, subsiquentType) Second (inconsistent), casting the secondUID with tonumber() makes more wrong results be returned. So whatever is happening is not consistently happening for secondUIDs that are integers. I initially found this by rexing a dashboard token list of secondUIDs so it isn't a matter of how the variables are being initially loaded from the lookup table. This is also shown by needing the eval command to cause the error which is distilled logic from an if statement. And as far as the inconsistency goes, there is no pattern to the numbers that are treated as numbers vs strings. Its not like all numbers starting with 0s have this happen or whitespace being around some.  Third (unexpected lookup function), if you looked at any of the events they would look correct. The values for secondUID would be correct and they have results returned for uID. Unless this is just another quirk of Splunk where wrong lookups are possible without warning, I would expect the |lookup to output a null() value when it is unable to use the key it is given.  Fourth (noticing the error), because Splunk doesn't give a warning and outputs a result, anybody using dedup or stats without a predetermined output expected would likely never know this exists. The only way I noticed it was because I knew there should be a 1-1 relation between my keys and values and there wasn't at the end of the search.  Fifth (event count dependent), since there is a higher % of errors happening when the initial event count goes up without a pattern in the secondUID values being passed in other than being "\d+", this makes me worried there is a memory allocation/referencing bug behind the scenes. Something which would probably also be fixed by tostring if this was the case. Counterpoint being that it reliably returns the same wrong lookup values. Maybe it really is just poor error handling in |lookup combined with typeof() being a lie. But I don't know how to come to a definitive conclusion without having access to the Splunk code (c/c++?) behind the scenes, or analyzing Splunk while it is running to rule out an allocation/referencing issue in absence of the |lookup code... Maybe you would have other ideas on how to narrow it down. Or maybe I'm just crazy        

Hi @AL3Z, You should go to default.xml at "Settings > User Interface > Navigation" menu while in your app. Use collection type for dropdown menus like below; Please update dropdown_menu_name1 and  dashboard_name1 with your needs. You can add more menus as you wish. <nav search_view="search" color="#1D1D1B"> <view name="search" default='true' /> <view name="reports" /> <view name="alerts" /> <view name="dashboards" /> <collection label="dropdown_menu_name1"> <view name="dashboard_name1"</> </collection> <collection label="dropdown_menu_name2"> <view name="dashboard_name2"</> </collection> </nav>  

Hi @scelikok  Below is my configuration of filelog receiver inside the helm chart  {{- if and (eq (include "splunk-otel-collector.logsEnabled" .) "true") (eq .Values.logsEngine "otel") }} {{- if .Values.logsCollection.containers.enabled }} filelog: {{- if .Values.isWindows }} include: ["C:\\var\\log\\pods\\*\\*\\*.log"] {{- else }} include: ["/var/log/pods/*/*/*.log"] {{- end }} # Exclude logs. The file format is # /var/log/pods/<namespace_name>_<pod_name>_<pod_uid>/<container_name>/<restart_count>.log exclude: {{- if .Values.logsCollection.containers.excludeAgentLogs }} {{- if .Values.isWindows }} - "C:\\var\\log\\pods\\{{ .Release.Namespace }}_{{ include "splunk-otel-collector.fullname" . }}*_*\\otel-collector\\*.log" {{- else }} - /var/log/pods/{{ .Release.Namespace }}_{{ include "splunk-otel-collector.fullname" . }}*_*/otel-collector/*.log {{- end }} {{- end }} {{- range $_, $excludePath := .Values.logsCollection.containers.excludePaths }} - {{ $excludePath }} {{- end }} start_at: beginning include_file_path: true include_file_name: false poll_interval: 200ms # Disable force flush until this issue is fixed: # https://github.com/open-telemetry/opentelemetry-log-collection/issues/292 retry_on_failure: enabled: true {{- end }} and also when I checked the config map start_at mapped with the beginning. Still it is not showing the older logs in Splunk 

https://docs.splunk.com/Documentation/Splunk/9.1.2/Admin/Inputsconf # For Windows systems only. # Does not use file handles [MonitorNoHandle://<path>] * This input intercepts file writes to the specific file. * <path> must be a fully qualified path name to a specific file. Wildcards and directories are not accepted. * This input type does not function on *nix machines. * You can specify more than one stanza of this type. disabled = <boolean> * Whether or not the input is enabled. * Default: 0 (enabled) index = <string> * Specifies the index where this input sends the data. * This setting is optional. * Default: the default index I have no experience using this myself and only learned about this in the last week.  Since you said the UF was on a Windows client this could work for you.  This would not work with a UF on *nix environments.