In particular, it does not preserve complete information about the events once you pass 10, 000 rows ( UPDATE: in more recent versions of Splunk this has increased to 500, 000). Splunk behaves a little different when the ‘search results’ are actually events. PITFALL # 1: base search is a “pure events” search that matches more than 10, 000 events.Skipping to the end – “what could go wrong?” Makes perfect sense, and it’s a TERRIBLE IDEA. The first thing everyone does is very intuitive – they make a “base search” that’s a simple search that returns raw events, and they make postProcess searches that contain transforming commands like stats or timechart. They allow you to dispatch only one “base search” get the events off disk only once, but then at request-time, carve up that base set of results in 2 or more different ways, to render different ‘slices’. Post process searches allow you to avoid this inefficiency. If you get the nagging feeling that there’s a better way, you’re right it’s called “postProcess” and it’s a part of the core Splunk API. You’re getting the same events off disk more than once and you’re making Splunk do extra work. Often you’ll see that a lot of searches are pretty similar to each other. After a while you’ve added and added, and you’re dispatching several searches. As you develop a custom view you start with one chart or one table.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |