We have around 10 services, by using below query i am getting 8 services and other 2 are not getting displayed in the table. But we can view them in events. Filed extraction is working correctly. not sure why other 2 services are not showing up in the table. please find the output. index=test-index (data loaded) OR ("GET data published/data/ui" OR "GET /v8/wi/data/*" OR "GET data/ui/wi/load/success") |rex field=_raw "DIP:\s+\[(?<dip>[^\]]+)." |rex field=_raw "ACTION:\s+(?<actions>\w+)" |rex dield=_raw "SERVICE:\s+(?<services>\S+)" |search actions= start OR actions=done NOT service="null" |eval split=services.":".actions |timechart span=1d count by split |eval _time=strftime(_time, "%d/%m/%Y") |table _time *start *done  Current output: (DCC:DONE &PIP:DONE  fields are missing) _time AAP:START ACC:START ABB:START DCC:START PIP:START AAP:DONE ACC:DONE ABB:DONE 1/2/2022 1 100 1 100 1 1 66 1 2/2/2022 5 0 5 0 3 3 0 3 3/2/2022 10 0 10 0 8 7 0 8 4/2/2022 100 1 100 1 97 80 1 80 5/2/2022 0 5 0 5 350 0 4 0   Expected output: _time AAP:START ACC:START ABB:START DCC:START PIP:START AAP:DONE ACC:DONE ABB:DONE DCC:DONE PIP:DONE 1/2/2022 1 100 1 100 1 1 66 1 99 1 2/2/2022 5 0 5 0 3 3 0 3 0 2 3/2/2022 10 0 10 0 8 7 0 8 0 3 4/2/2022 100 1 100 1 97 80 1 80 1 90 5/2/2022 0 5 0 5 350 0 4 0 5 200  

Hi Tony, Based on the first screen capture, the javaagent node is not reporting to the controller (it's showing 0% for status) and this is the reason it's not showing up in the dashboard. We will need to take a look at the logs to understand the reason why the agent is unable to establish connection with the controller. Could you capture the logs for the node that is not reporting and attach them here (docs on capturing logs - https://docs.appdynamics.com/appd/24.x/24.3/en/application-monitoring/install-app-server-agents/java-agent/administer-the-java-agent/java-agent-logging). After initial analysis we will let you know if we need to collect any additional information. Thanks

Are you sure that your raw event is not a valid JSON closer to   {"date": "1/2/2022 00:12:22,124", "DATA": "[http:nio-12567-exec-44] DIP: [675478-7655a-56778d-655de45565] Data: [7665-56767ed-5454656] MIM: [483748348-632637f-38648266257d] FLOW: [NEW] { SERVICE: AAP | Applicationid: iis-675456 | ACTION: START | REQ: GET data published/data/ui } DADTA -:TIME:<TIMESTAMP> (0) 1712721546785 to 1712721546885 ms GET /v8/wi/data/*, GET data/ui/wi/load/success", "tags": {"host": "GTU5656", "insuranceid": "8786578896667", "lib": "app"}}   instead?  In other words, do you not have a field  named "DATA" already? Because the overall structure of your illustration is very much compliant. Assuming you have a field named DATA, a better strategy is trying to reconstruct a structure as your developers intended, instead of trying to extract individual tidbits as random text because your developers have clearly put in thoughts about data structure within DATA.  I would propose something like   index=test-index (data loaded) OR ("GET data published/data/ui" OR "GET /v8/wi/data/*" OR "GET data/ui/wi/load/success") | rex field=DATA mode=sed "s/ *[\|}\]]/\"/g s/: *\[*/=\"/g" | rename _raw as temp | rename DATA AS _raw | kv | rename temp as _raw   Your sample data should give you ACTION Applicationid DIP Data FLOW MIM REQ SERVICE date http tags.host tags.insuranceid tags.lib START iis-675456 675478-7655a-56778d-655de45565 7665-56767ed-5454656 NEW 483748348-632637f-38648266257d GET data published/data/ui AAP 1/2/2022 00:12:22,124 nio-12567-exec-44 GTU5656 8786578896667 app Here is an emulation that results in my hypothesized raw log:   | makeresults | eval _raw = "{\"date\": \"1/2/2022 00:12:22,124\", \"DATA\": \"[http:nio-12567-exec-44] DIP: [675478-7655a-56778d-655de45565] Data: [7665-56767ed-5454656] MIM: [483748348-632637f-38648266257d] FLOW: [NEW] { SERVICE: AAP | Applicationid: iis-675456 | ACTION: START | REQ: GET data published/data/ui } DADTA -:TIME:<TIMESTAMP> (0) 1712721546785 to 1712721546885 ms GET /v8/wi/data/*, GET data/ui/wi/load/success\", \"tags\": {\"host\": \"GTU5656\", \"insuranceid\": \"8786578896667\", \"lib\": \"app\"}}" | spath ``` the above emulates index=test-index (data loaded) OR ("GET data published/data/ui" OR "GET /v8/wi/data/*" OR "GET data/ui/wi/load/success") ```   Play with the emulation and compare with real data. Note: In the unimaginable case where your developers try really hard to mess up everybody's mind and inject semblance of JSON compliance while violating common sense, you can still apply the same principle against _raw.  Like this:   index=test-index (data loaded) OR ("GET data published/data/ui" OR "GET /v8/wi/data/*" OR "GET data/ui/wi/load/success") ``` | rex mode=sed "s/ *[\|}\]]/\"/g s/: *\[*/=\"/g" | kv   This is what the output would look like: ACTION Applicationid DATA DIP Data FLOW MIM REQ SERVICE host START iis-675456 http= 675478-7655a-56778d-655de45565 7665-56767ed-5454656 NEW 483748348-632637f-38648266257d GET data published/data/ui AAP   Without a better structure, you won't get subnodes embedded in tags; but your original question does not seem to care about tags. Here is an emulation that resembles the actual sample you posted:   | makeresults | eval _raw = "{\"date\": \"1/2/2022 00:12:22,124\", DATA: [http:nio-12567-exec-44] DIP: [675478-7655a-56778d-655de45565] Data: [7665-56767ed-5454656] MIM: [483748348-632637f-38648266257d] FLOW: [NEW] { SERVICE: AAP | Applicationid: iis-675456 | ACTION: START | REQ: GET data published/data/ui } DADTA -:TIME:<TIMESTAMP> (0) 1712721546785 to 1712721546885 ms GET /v8/wi/data/*, GET data/ui/wi/load/success\", \"tags\": {\"host\": \"GTU5656\", \"insuranceid\": \"8786578896667\", \"lib\": \"app\"}}" ``` the above emulates index=test-index (data loaded) OR ("GET data published/data/ui" OR "GET /v8/wi/data/*" OR "GET data/ui/wi/load/success") ```  

Hi All, I'm sorry for not replying sooner. I have been out of the office and did not have a chance to reply.   The reply from Terence is not what we were looking for, but it may be an answer to the issue.   We plan to test the answer from Terence over the next week or so.  Please stay tuned. 

Were you able to find an answer to your question? I know there are lots of SAP customers who face the same problem.  Take a look at PowerConnect. It works out of the box and pulls in SAP CPI logs and many other SAP SaaS offerings. It also helps cut down on meat time to detect / resolve other performance and security issues.

Sample logs: {"date": "1/2/2022 00:12:22,124" DATA [http:nio-12567-exec-44] DIP: [675478-7655a-56778d-655de45565] Data: [7665-56767ed-5454656] MIM: [483748348-632637f-38648266257d] FLOW: [NEW] { SERVICE: AAP | Applicationid: iis-675456 | ACTION: START | REQ: GET data published/data/ui } DADTA -:TIME:<TIMESTAMP> (0) 1712721546785 to 1712721546885 ms GET /v8/wi/data/*, GET data/ui/wi/load/success, "tags": {"host": "GTU5656", "insuranceid": "8786578896667", "lib": "app"}} Sample logs: {"date": "1/2/2022 00:12:22,124" DATA [http:nio-12567-exec-44] DIP: [675478-7655a-56778d-655de45565] Data: [7665-56767ed-5454656] MIM: [483748348-632637f-38648266257d] FLOW: [NEW] { SERVICE: AAP | Applicationid: iis-675456 | ACTION: DONE | REQ: GET data published/data/ui } DADTA -:TIME:<TIMESTAMP> (0) 1712721546785 to 1712721546885 ms GET /v8/wi/data/*, GET data/ui/wi/load/success, "tags": {"host": "GTU5656", "insuranceid": "8786578896667", "lib": "app"}}   Hi @PickleRick , added sample logs, let me know if u need any other details.

It's a bit more complicated than that. 1. As @richgalloway pointed out, UF is by default capped with maxKBps (which is a rough value - there is no guarantee for Splunk to _always_ process no more than that value per second). 2. Even if you set the limit to 0 (no limit at all), the back pressure from output will make the forwarder to stop reading the file until the queue empties a bit. Generally, the "speed" of Splunk reading files depends mostly on non-Splunk limits (like output rate which might be limited by receiving instance performance or network bandwidth or input rate if the file is placed on a network share). Also since the limits apply to the general overall size of the data regardless of how big the events are, the EPS value isn't that important here - the same limit will apply if you send just a few big events as when you send many small ones. But there is also one more thing worth pointing out - UF doesn't (typically, unless you use indexed extractions on structured data) deal with events as such - it reads and sends to an output chunks of data for breaking into events "further down the road" (on indexers or heavy forwarders). With sufficiently modern UF and configured EVENT_BREAKER, you should be sending chunks of data ending on event boundary, but you typically don't send single events (unless they are huge).