The solution given does work and it is exactly what I am looking for. The value{0} does correspond to dsnames{0}, and value{1} to dsnames{1}. I am unfortunately not able to change the logs.   The only problem I have still is that the max for read and write is displaying the same number and I am almost certain they should be different numbers.   This is the current search   index="collectd_test" plugin=disk type=disk_octets plugin_instance=dm-0 | eval data = mvappend(json_object("dsname", mvindex('dsnames{}', 0), "value", mvindex('values{}', 0)), json_object("dsname", mvindex('dsnames{}', 1), "value", mvindex('values{}', 1))) | mvexpand data | spath input=data | stats min(value) as min max(value) as max avg(value) as avg by dsname | eval min=round(min, 2) | eval max=round(max, 2) | eval avg=round(avg, 2)   This is the raw text of the JSON event.   {"values":[0,35225.165651947],"dstypes":["derive","derive"],"dsnames":["read","write"],"time":1700320094.109,"interval":10.000,"host":"usorla7sw101x.ad101.siemens-energy.net","plugin":"disk","plugin_instance":"dm-0","type":"disk_octets","type_instance":"","meta":{"network:received":true,"network:ip_address":"129.73.170.204"}}   This is the current output. dsname min           max                           avg read 0.00 192626230.85 53306.64 write 0.00 192626230.85 65185.22

UF does not have web interface. Every other component, based on the full Splunk Enterprise package can have its own webui. But whether this webui will be on depends on your particular needs and architecture. Indexers are typically run headless (without web interface). Search-heads are typically run with web interface (there are very rare cases when the search-head can be run headless but these are really border cases). Deployment Server can be run with or without webui depending on how you're going to manage it. HF can be run with or without webui (the core functionality - receiving and forwarding data - can be run without webui perfectly well but some apps need webui to initially configure them). So it's a bit complicated

Something's not right in that screenshot.  The contents of indexes.conf should not be indexed.  I suspect some instructions are being misinterpreted. Please tell us more details about how you are trying to load the data.  Provide the exact steps followed or a link to them.

Hi @blkscorpio , I think that you should read something about Splunk architecture. Anyway, Spunk UF and HF are different packages: UF is a thin agent to install to ingest logs, instead HF is a Full Splunk instance (with a different package) where are used only the ingestion and forwardring features. The HF has also all the UF's features and many other things. UF hasn't a web interface, only HF has a web interface. Start from Fundamentals I training to have the first introduction to Splunk. Ciao. Giuseppe  

OK. Splunk terminology can be a bit confusing for newcomers So let's straighten that a bit. There are two separate installation packages that you can download: - Universal Forwarder - "full" Splunk Enterprise installer. So Universal Forwarder is a relatively small instance with limited functionality meant only to be used for getting data using some subset of input types and forward the data downstream. It cannot do local indexing or searching, it doesn't have some other functionalities (like syslog forwarding). Everything else you install from the Splunk Enterprise installer and you end up with a Splunk Enterprise server which can have one or more roles: - indexer - search head - cluster manager - license manager - search head cluster deployer - deployment server - heavy forwarder (you can also install an "all-in-one" instance performing both indexer and search head duties). Heavy Forwarder is basically a Splunk Enterprise instance that does not perform local indexing - it doesn't store data it receives either from local inputs or from other forwarders locally but processes the events and forwards them to outputs (either another layer of forwarders or indexers). So "forwarder" as a general term is a component which gets the data somehow and forwards it - it can be an UF or HF depending on which software package is used to install the server.

First and foremost - often the key to speeding up the search is just writing a good search. Typically you don't just search for all events from a given index - you either look for something specific or transform the data to get some meaningful summary. Having said that - there are so many points where things can go slow (network links, performance and resources of single hosts, data distribution, the load on your environment) that it's impossible to give a "general" answer. So architecture is one thing (and you really should get your local friendly Splunk Partner involved to design an architecture fitting your specific needs - including resilience, HA, capacity and specific use cases) but troubleshooting existing environment is another. You can verify what your search is waiting for using the "Inspect Job" button.

1. If I remembered correctly you said that you were extracting host from the whole "packed" event - before casting it to the destination sourcetype. It was just to demonstrate that it works and cloned event inherits the indexed fields which had already been extracted before the event was cloned. That's all. If you're gonna extract the host from the "embedded" event after casting it to the destination sourcetype, no problem, you can remove that transform from the source sourcetype. The transforms extracting source and host were just inserted to demonstrate the inheritance and "overwriting" fields in case of event cloning. They are not essential for the cloning as such. 2. The conditional_host_overwrite transform was to show you that even though the host field gets overwritten in the source sourcetype the transform will get executed in the destination sourcetype so your cloning does indeed do what you wanted - fire transforms from the destination sourcetype to which the events get cloned. The main takeouts from this exercise are that: 1. Indexed fields get cloned with the CLONE_SOURCETYPE functionality 2. _ALL_ events to which the given props get applied (so all matching given sourcetype, source or host - depending on how you assign your transforms to events) get cloned so you have to selectively filter them in the source sourcetype and destination sourcetype. 3. Props/transforms from the destination sourcetype get applied after the event gets cloned 4. Order of transforms is important.

Hi @PickleRick , thank you very much for you answer, I will try it on Monday  and I'm confident that it will run. Only two explanations, to better understand you solution:  you hint to extract host and source before cloning sourcetype, but how these two fields are passed to the cloned sourcetype? what's the purpose of the "TRANSFORMS-conditional_host_overwrite" command in the cloned sourcetype? must I add also a similar command for source field? Ciao and thank you very much. Giuseppe

Please use raw text to post sample JSON events, not screenshot and not Splunk's contracted pretty format. Do you mean the value{0} correspond to dsnames{0}, and value{1} to dsnames{1}? This is about as wasteful as JSON data design goes.  If you have influence on developers who wrote these logs, implore them to change the structure to array of hashes instead of hash of arrays.  Like this:   {"whatever": [ {"dsname":"read", "dstype":"typefoo", "value": 123}, {"dsname":"write", "dstype":"typebar", "value": 456} ] }   Before that happens, you can contain the damage from your developers' crimes with some reconstruction.  Traditionally, this is done with string concatenation; and usually, you need mvmap to handle indeterminant number or large number of array elements. In this case, there are only two semantic values so I'll not be bothered with mvmap.  I will also use structured JSON instead of string concatenation. (JSON function was introduced in Splunk 8.0.)   | eval data = mvappend(json_object("dsname", mvindex('dsnames{}', 0), "value", mvindex('values{}', 0)), json_object("dsname", mvindex('dsnames{}', 1), "value", mvindex('values{}', 1))) | mvexpand data | spath input=data | stats min(value) as min max(value) as max avg(value) as avg by dsname | eval min=round(min, 2) | eval max=round(max, 2) | eval avg=round(avg, 2)   Here is some mock data that I use to test the above _raw dsnames{} values{} {"dsnames": ["read", "write"], "values": [123, 234]} read write 123 234 {"dsnames": ["read", "write"], "values": [456, 567]} read write 456 567 This is an emulation to get the above   | makeresults | eval data=mvappend("{\"dsnames\": [\"read\", \"write\"], \"values\": [123, 234]}", "{\"dsnames\": [\"read\", \"write\"], \"values\": [456, 567]}") | mvexpand data | rename data as _raw | spath ``` data emulation above ```   You can play with this and compare with real data.  This mock data gives dsname min max avg read 123.00 456.00 289.50 write 234.00 567.00 400.50

Hi @Zodi_6 , see the transpose command at https://docs.splunk.com/Documentation/Splunk/9.1.2/SearchReference/Transpose and, please, try: index=_internal source="*license_usage.log" | eval bytes=b | eval GB = round(bytes/1024/1024/1024,3) | timechart span=1d sum(GB) by h | transpose 0 column_name=h header_field_time Ciao. Giuseppe