sooo... hier nun ein paar Gedanken dazu. Ich hab mich mit meinen Kollegen dazu mal ausgetauscht.
Generell ist es so, dass man GDI (get your data in) normalerweise nicht in Cloud macht sondern auf Forwardern, die in der eigenen Infrastruktur deployed sind. Bei Heavy Forwardern (die mit UI, bei denen alle Daten an einen Indexer Layer wie z.B. bei Splunk Cloud) ist es genauso: man installiert sie in der eignen Infrastruktur z.B. um mit DB Connect aus lokalen Datenbanken was rauszuholen und dann in den Indexing Layer zu schicken.
Aber: es gibt eben auch Modular Inputs im Cloud Umfeld, wo APIs abgepollt werden... z.B . beim AWS addon oder beim GCP Addon (wobei Datensenken, bei denen die Sachen an Splunk geschickt werden immer besser sind btw).
Fuer solche Zwecke gibt's Neuerdings de IDM. Den Inputs Data Manager. Das Ganze ist hier vorgestellt worden:
https://www.splunk.com/en_us/blog/platform/introducing-inputs-data-manager-on-splunk-cloud.html
Ist also Bestandteil vom Splunk Cloud Offering.. also Splunk SaaS.
Falls ihr dann TA's darauf laufen lassen wolltet., muesstet ihr damit durch's App Vetting. Dabei gibt's dann aber 2-3 Sachen zu beachten:
- Die app sollte aufgeteilt werden: was muss in den IDM (der eigenen HFW), was muss auf den Indexer und was muss auf den Search Head (Cluster)? Paketiert danach.
- gibt nur die Teile ins App Vetting, die ihr in Cloud braucht. Wenn ihr den Datensammler in einer selber gehosteten VPC laufen laesst, braucht ihr kein App Vetting fuer diese Paket.
- Benutzt AppInspect um zu checken, ob die Pakete Cloud-kompatibel sind... ABER benutzt die API Version, die ist immer aktuell: https://dev.splunk.com/enterprise/docs/developapps/testvalidate/appinspect/cloudvettingguidelines/ve...
Hier ist der Aufruf der dazu aus der Doku:
curl -X POST \
-H "Authorization: bearer <token>" \
-H "Cache-Control: no-cache" \
-F "app_package=@\"app_path/app_filename.tgz\"" \
-F "included_tags=cloud" \
--url "https://appinspect.splunk.com/v1/app/validate"
