Enlaces¶

Listado útil de sitios, documentación oficial y recursos externos.

Este documento reúne los enlaces que se utilizarán durante el curso y el proyecto final de monitorización de una aplicación web con Splunk Enterprise.

Los enlaces se han organizado por temática para que los asistentes puedan encontrar rápidamente la referencia adecuada durante una práctica o una actividad de troubleshooting.

La documentación principal debe consultarse siempre junto con las pruebas realizadas en la instancia del laboratorio.

1. Información del entorno de referencia¶

El laboratorio utiliza como referencia:

Splunk Enterprise 10.4.3.
Ubuntu 24.04.5 LTS.
Arquitectura mononodo.
Splunk Web en http://localhost:8000.
Índice principal: curso.
Usuario de configuración: admin.
Dataset principal: eventos web.

Las rutas, menús y capacidades pueden variar según:

versión de Splunk;
tipo de dashboard;
permisos del usuario;
sistema operativo;
método de ingesta;
aplicación desde la que se crean los objetos;
configuración de seguridad;
topología de la plataforma.

Antes de aplicar una instrucción, comprueba que es compatible con la versión del laboratorio.

2. Documentación oficial de Splunk¶

La documentación oficial de Splunk debe ser la primera fuente de consulta para resolver dudas sobre configuración, SPL, dashboards, alertas y permisos.

Splunk Enterprise Documentation¶

Documentación general del producto.

Incluye información sobre:

administración;
búsquedas;
indexación;
entradas de datos;
dashboards;
alertas;
seguridad;
usuarios;
aplicaciones;
API REST;
troubleshooting.
Splunk Enterprise Documentation

Splunk Help¶

Portal de ayuda con documentación organizada por producto, versión y área funcional.

Splunk Help

Splunk Enterprise 10.4¶

Página de referencia de la documentación correspondiente a la rama 10.4.

Splunk Enterprise 10.4 Documentation

Notas de versión¶

Antes de aplicar una configuración, revisa las notas de versión si sospechas que existe una diferencia de comportamiento entre versiones.

Splunk Enterprise Release Notes

Las notas de versión pueden incluir información sobre:

nuevas funcionalidades;
cambios de comportamiento;
problemas conocidos;
funcionalidades obsoletas;
requisitos del sistema;
cambios de seguridad;
problemas de compatibilidad.

3. Búsqueda y lenguaje SPL¶

Estas referencias son esenciales para las prácticas de búsqueda, cálculo de métricas y creación de resultados para dashboards.

Search Manual¶

Manual general sobre búsquedas en Splunk.

Splunk Search Manual

Utilízalo para comprender:

cómo funciona Search & Reporting;
cómo se selecciona un intervalo temporal;
cómo se ejecutan las búsquedas;
cómo se guardan búsquedas;
cómo se interpretan los resultados;
cómo se utilizan campos;
cómo se investigan eventos.

Search Reference¶

Referencia técnica de comandos, funciones y operadores SPL.

Splunk Search Reference

Resulta especialmente útil para consultar:

stats;
eval;
where;
search;
table;
fields;
sort;
head;
tail;
timechart;
chart;
eventstats;
streamstats;
rex;
spath;
dedup;
rename;
lookup;
fieldsummary.

Comando `stats`¶

stats

Ejemplo:

index=curso earliest=0 latest=now
| stats count as total_eventos

Ejemplo agrupado:

index=curso earliest=0 latest=now
| stats count as peticiones by host
| sort - peticiones

Ejemplo con varias métricas:

index=curso earliest=0 latest=now
| stats
    count as peticiones
    count(eval(status=500)) as errores_500
    dc(uri) as uri_distintas

Comando `eval`¶

eval

Ejemplo de conversión numérica:

index=curso earliest=0 latest=now
| eval status_num=tonumber(status)

Ejemplo de clasificación:

index=curso earliest=0 latest=now
| eval clase_http=case(
    status_num>=500, "5xx",
    status_num>=400, "4xx",
    status_num>=300, "3xx",
    status_num>=200, "2xx",
    true(), "otro"
)

Comando `where`¶

where

Ejemplo:

index=curso earliest=0 latest=now
| eval status_num=tonumber(status)
| where status_num>=400

where resulta especialmente útil después de crear un campo calculado.

Comando `timechart`¶

timechart

Ejemplo:

index=curso earliest=0 latest=now
| timechart span=1m count as peticiones

Ejemplo separando respuestas correctas y errores:

index=curso earliest=0 latest=now
| eval status_num=tonumber(status)
| eval resultado=if(status_num>=400, "Error", "Correcta")
| timechart span=1m count by resultado

Comando `fieldsummary`¶

fieldsummary

Ejemplo:

index=curso earliest=0 latest=now
| fieldsummary

Utiliza esta búsqueda cuando no conozcas los nombres reales de los campos del dataset.

Búsqueda optimizada¶

Search Optimization

Buenas prácticas:

indica el índice;
utiliza un intervalo temporal;
filtra pronto;
evita index=* salvo diagnóstico;
evita table *;
limita resultados cuando proceda;
no ejecutes búsquedas históricas muy amplias sin necesidad;
documenta búsquedas utilizadas por alertas;
comprueba el coste de reportes programados.

4. Ingesta y entrada de datos¶

Estas referencias ayudan a entender cómo se incorporan eventos a Splunk.

Get Data In¶

Get Data In

Utiliza esta referencia para estudiar:

carga de archivos;
monitorización de directorios;
entradas de red;
fuentes de datos;
selección de índice;
selección de sourcetype;
revisión de la vista previa.

How Splunk Processes Data¶

How Splunk Processes Data

Explica el recorrido general:

Entrada
    ↓
Parsing
    ↓
Asignación de metadatos
    ↓
Indexación
    ↓
Búsqueda

Esta referencia resulta útil para diagnosticar por qué un archivo existe en Ubuntu, pero todavía no aparece en Splunk.

Monitor Files and Directories¶

Monitor Files and Directories

Ejemplo de entrada monitorizada:

/var/log/splunk-curso/eventos_web.csv

Ejemplo conceptual de configuración:

[monitor:///var/log/splunk-curso/eventos_web.csv]
disabled = false
index = curso
sourcetype = web:csv
host = web-lab

Antes de configurar una monitorización, comprueba:

ls -ld /var/log/splunk-curso
ls -l /var/log/splunk-curso/eventos_web.csv

Source Types¶

About Source Types

Los sourcetypes ayudan a indicar cómo debe interpretar Splunk una fuente.

Ejemplos utilizados en el curso:

web:csv
web:csv:extended
curso_web_csv

El nombre debe ser consistente entre:

entrada;
documentación;
búsquedas;
reportes;
dashboards;
alertas.

Inputs¶

Inputs.conf

Esta referencia es útil cuando el asistente debe revisar o crear una entrada de monitorización mediante configuración.

Ejemplo:

[monitor:///var/log/splunk-curso/eventos_incrementales.csv]
disabled = false
index = curso
sourcetype = web:csv
host = web-lab

No modifiques una configuración de producción sin revisar previamente:

aplicación;
contexto de configuración;
permisos;
prioridad de archivos;
necesidad de reinicio o recarga;
impacto sobre otras entradas.

5. Índices y almacenamiento¶

About Indexes¶

About Indexes

Utiliza esta referencia para comprender:

índices;
almacenamiento;
retención;
buckets;
hot, warm, cold y frozen;
permisos;
configuración general;
diferencias entre índices internos y de datos.

Indexes.conf¶

Indexes.conf

Referencia de configuración del archivo indexes.conf.

Ejemplo de consulta para revisar el índice:

| rest /services/data/indexes
| search title=curso
| table title disabled totalEventCount currentDBSizeMB

Buenas prácticas para el índice del curso¶

Utiliza un índice específico:

curso

Evita almacenar datos de prácticas en índices no relacionados.

Documenta:

nombre;
finalidad;
propietario;
retención;
permisos;
fuentes;
sourcetypes;
usuarios autorizados.

Consultar varios índices¶

Durante el troubleshooting puede utilizarse:

index=curso OR index=_internal

No utilices esta consulta como búsqueda normal de los dashboards del proyecto.

6. Dashboards y visualizaciones¶

Dashboards¶

Splunk Dashboards

Referencia general para trabajar con dashboards y visualizaciones.

Dashboard Studio¶

Dashboard Studio

Dashboard Studio permite crear dashboards con controles, visualizaciones y configuración más flexible.

Utilízalo para estudiar:

paneles;
controles;
tokens;
filtros;
layouts;
visualizaciones;
interacción entre componentes.

Classic Dashboards¶

Classic Dashboards

Referencia útil si el laboratorio utiliza dashboards clásicos o XML simplificado.

Selección de visualizaciones¶

Necesidad	Visualización recomendada
Total de eventos	Single value
Porcentaje de error	Single value o gauge
Evolución temporal	Línea
Errores por código	Barras o columnas
URI con más errores	Tabla o barras
Host con más errores	Barras o tabla
Últimos eventos	Tabla
Distribución de métodos	Barras o donut
Latencia por URI	Tabla o barras
Comparación entre métricas	Gráfico combinado

Ejemplo de panel de errores por código¶

index=curso earliest=$time.earliest$ latest=$time.latest$
| eval status_num=tonumber(status)
| stats count as errores by status_num
| sort status_num

Ejemplo de panel temporal¶

index=curso earliest=$time.earliest$ latest=$time.latest$
| eval status_num=tonumber(status)
| eval resultado=if(status_num>=400, "Error", "Correcta")
| timechart span=1m count by resultado

La sintaxis exacta de los tokens depende del tipo de dashboard. Comprueba el formato utilizado por la instancia.

Buenas prácticas para dashboards¶

Un dashboard debe:

tener un objetivo;
utilizar títulos comprensibles;
mostrar primero los indicadores principales;
permitir investigar el detalle;
utilizar un intervalo temporal;
tener filtros probados;
evitar paneles duplicados;
mostrar alternativas si faltan campos;
documentar el comportamiento sin datos;
ser visible para el usuario final;
no depender exclusivamente del rol admin.

7. Alertas¶

About Alerts¶

About Alerts

Referencia principal para crear, configurar y administrar alertas.

Ejemplo de alerta del proyecto¶

index=curso earliest=-5m latest=now
| eval status_num=tonumber(status)
| stats count(eval(status_num=500)) as errores_500
| where errores_500>=5

La condición es:

Cinco o más respuestas HTTP 500 durante los últimos cinco minutos.

Elementos que deben documentarse¶

nombre;
propietario;
aplicación;
consulta;
frecuencia;
ventana temporal;
condición;
acción;
destinatario;
throttling;
resultado de la prueba;
actuación posterior.

Prueba histórica¶

index=curso earliest="01/01/2026:00:00:00"
          latest="01/01/2026:00:10:00"
| eval status_num=tonumber(status)
| stats count(eval(status_num=500)) as errores_500
| where errores_500>=5

Esta búsqueda valida la lógica sobre datos históricos.

No debe presentarse como una prueba de funcionamiento en tiempo real.

Alertas y permisos¶

Alert Permissions

Los permisos y capacidades determinan quién puede:

crear una alerta;
ejecutar una alerta;
editarla;
visualizarla;
modificar sus acciones;
compartirla.

8. Usuarios, roles y seguridad¶

Role-Based User Access¶

About Configuring Role-Based User Access

Esta referencia explica cómo controlar el acceso a:

índices;
dashboards;
aplicaciones;
recursos de la plataforma;
objetos de conocimiento.

Los siguientes objetos deben tratarse como objetos de conocimiento:

búsquedas guardadas;
reportes;
dashboards;
alertas;
lookups;
macros;
campos calculados;
event types.

Principio de mínimo privilegio¶

En producción:

no todos los usuarios necesitan admin;
los analistas pueden tener permisos de búsqueda limitados;
los usuarios finales pueden tener únicamente permisos de lectura;
los propietarios de objetos deben estar definidos;
el acceso al índice debe ser explícito;
las alertas deben tener responsables;
la modificación de dashboards debe estar controlada.

Revisar el contexto del usuario¶

| rest /services/authentication/current-context
| table username roles

Revisar objetos compartidos¶

La compartición de un dashboard o reporte debe documentarse junto con:

aplicación;
propietario;
permisos de lectura;
permisos de escritura;
audiencia;
dependencia de búsquedas privadas.

9. API REST de Splunk¶

Splunk REST API Reference¶

Splunk REST API Reference

La API REST puede utilizarse para consultar:

índices;
entradas;
usuarios;
roles;
búsquedas guardadas;
alertas;
dashboards;
configuración;
estado de la plataforma.

Revisar entradas monitorizadas¶

| rest /services/data/inputs/monitor
| table eai:acl.app path index sourcetype disabled

Revisar índices¶

| rest /services/data/indexes
| table title disabled totalEventCount currentDBSizeMB

Revisar el usuario actual¶

| rest /services/authentication/current-context
| table username roles

La API debe utilizarse respetando:

autenticación;
autorización;
certificados;
protección de credenciales;
auditoría;
permisos del usuario.

No incluyes tokens, contraseñas ni credenciales en archivos Markdown, capturas o scripts compartidos.

10. Sistema operativo Ubuntu¶

Ubuntu Server Documentation¶

Ubuntu Server Documentation

Systemd¶

Ubuntu Systemd

Comandos utilizados en el laboratorio¶

Estado del servicio¶

sudo systemctl status Splunkd

Estado mediante Splunk¶

sudo /opt/splunk/bin/splunk status

Versión instalada¶

/opt/splunk/bin/splunk version

Puertos abiertos¶

sudo ss -lntp | grep -E '8000|8089|9997'

Permisos de una ruta¶

ls -ld /var/log/splunk-curso

Permisos de un archivo¶

ls -l /var/log/splunk-curso/eventos_web.csv

Qué comprobar en Ubuntu¶

Cuando Splunk no ingiere un archivo, revisa:

existencia de la ruta;
permisos del directorio;
permisos del archivo;
usuario que ejecuta Splunk;
procesos;
servicio;
puertos;
espacio disponible;
formato del archivo;
crecimiento del archivo.

11. Troubleshooting¶

Índice de troubleshooting¶

Splunk Troubleshooting

Diagnóstico mediante `_internal`¶

index=_internal earliest=-30m latest=now
| search log_level=error OR log_level=warn
| table _time host component log_level message
| sort - _time

Problema: no aparecen eventos¶

Consulta inicial:

index=curso earliest=0 latest=now
| stats count

Después revisa:

index=curso earliest=0 latest=now
| stats count by host source sourcetype

Y:

index=curso earliest=0 latest=now
| fieldsummary

Problema: el archivo existe, pero no aparece en Splunk¶

Revisa:

ls -ld /ruta
ls -l /ruta/archivo.csv

Después consulta:

| rest /services/data/inputs/monitor
| table path index sourcetype disabled

Problema: el timestamp no se reconoce¶

Revisa:

index=curso earliest=0 latest=now
| stats min(_time) as inicio max(_time) as fin

Compara con:

index=curso earliest=0 latest=now
| table _time _indextime _raw
| head 20

Problema: el campo no existe¶

Ejecuta:

index=curso earliest=0 latest=now
| fieldsummary

Después revisa el evento original:

index=curso earliest=0 latest=now
| table _raw
| head 20

Problema: la alerta no se dispara¶

Comprueba:

existencia de eventos recientes;
timestamps dentro de los últimos cinco minutos;
presencia de valores 500;
consulta ejecutada manualmente;
estado habilitado de la alerta;
frecuencia;
throttling;
permisos;
acción configurada.

Consulta de diagnóstico:

index=curso earliest=-5m latest=now
| eval status_num=tonumber(status)
| where status_num=500
| stats count as errores_500

12. Observabilidad y monitorización web¶

Splunk permite analizar eventos, pero una monitorización completa de una aplicación web suele combinar logs, métricas, trazas y disponibilidad.

Temas externos recomendados¶

Busca documentación y artículos sobre:

observabilidad;
monitorización de APIs;
códigos HTTP;
latencia;
percentiles;
disponibilidad;
errores de aplicación;
saturación;
capacidad;
experiencia de usuario;
gestión de incidentes;
detección de anomalías.

Indicadores habituales¶

Una aplicación web puede observarse mediante:

volumen de peticiones;
tasa de errores;
latencia;
disponibilidad;
códigos HTTP;
URI problemáticas;
hosts afectados;
IP de origen;
saturación;
tiempos de respuesta;
tamaño de respuesta.

Relación con el proyecto¶

El proyecto trabaja principalmente con:

Volumen
Errores
Códigos HTTP
URI
Host
IP, si existe
Latencia, si existe

No debes confundir:

volumen con disponibilidad;
error 4xx con fallo del servidor;
error 5xx con causa raíz demostrada;
media de latencia con experiencia de todos los usuarios;
host con IP de cliente.

13. Recursos externos recomendados¶

Los recursos externos pueden complementar la documentación oficial, pero deben utilizarse con criterio.

Tipos de recursos útiles¶

documentación oficial de Ubuntu;
documentación del servidor web;
documentación de la aplicación;
documentación de bases de datos;
artículos técnicos de observabilidad;
guías de HTTP;
publicaciones sobre rendimiento;
libros de administración de sistemas;
artículos sobre detección de anomalías;
documentación de seguridad.

Criterios para seleccionar un recurso externo¶

Comprueba:

autor;
organización;
fecha;
versión;
propósito;
reputación de la fuente;
relación con el problema;
posibilidad de verificar el contenido;
compatibilidad con Splunk Enterprise 10.4.3.

Evita utilizar como única fuente:

fragmentos de buscadores;
respuestas sin contexto;
publicaciones sin fecha;
páginas sin autor;
ejemplos sin versión;
contenido que no pueda reproducirse;
configuraciones copiadas sin comprobar.

Cómo registrar un recurso externo¶

#### Nombre del recurso

- Tipo: artículo, libro, guía o documentación
- Autor:
- Organización:
- Fecha:
- URL:
- Tema:
- Relación con el proyecto:
- Fecha de consulta:
- Observaciones:

Ejemplo¶

#### Guía sobre monitorización de aplicaciones web

- Tipo: artículo técnico
- Autor: ____________________
- Organización: ____________________
- Fecha: ____________________
- URL: ____________________
- Tema: latencia y tasa de errores
- Relación con el proyecto: ayuda a interpretar los paneles de rendimiento
- Fecha de consulta: ____________________
- Observaciones: debe contrastarse con los datos reales del laboratorio

14. Enlaces organizados por actividad¶

Actividad: preparar el entorno¶

Actividad: crear o revisar un índice¶

Actividad: ingerir un CSV¶

Actividad: explorar datos¶

Actividad: escribir SPL¶

Actividad: crear dashboards¶

Actividad: crear alertas¶

Actividad: revisar permisos¶

Actividad: consultar la API¶

Splunk REST API Reference

Actividad: diagnosticar errores¶

15. Ejemplos prácticos de uso de los enlaces¶

Ejemplo 1: no aparecen datos¶

Situación¶

El asistente ejecuta:

index=curso earliest=-15m latest=now

y no obtiene resultados.

Enlaces que debe consultar¶

documentación de búsqueda;
documentación de entradas;
documentación de índices;
documentación de troubleshooting.

Secuencia práctica¶

index=curso earliest=0 latest=now
| stats count

Después:

| rest /services/data/inputs/monitor
| table path index sourcetype disabled

Y finalmente:

index=_internal earliest=-30m latest=now
| search log_level=error OR log_level=warn
| table _time component log_level message
| sort - _time

Conclusión esperada¶

El asistente debe diferenciar entre:

no hay eventos;
el rango es incorrecto;
el índice es incorrecto;
la entrada está deshabilitada;
el archivo no tiene permisos;
el timestamp está fuera de la ventana;
existe un error de configuración.

Ejemplo 2: el dashboard muestra paneles vacíos¶

Situación¶

El dashboard se abre, pero varios paneles no muestran datos.

Comprobaciones¶

ejecutar la búsqueda del panel fuera del dashboard;
sustituir temporalmente los tokens por valores fijos;
ampliar el rango temporal;
comprobar el índice;
revisar los campos;
probar el usuario final;
comprobar permisos de la búsqueda guardada.

Consulta base¶

index=curso earliest=0 latest=now
| stats count

Consulta de campos¶

index=curso earliest=0 latest=now
| fieldsummary

Conclusión esperada¶

No debe modificarse el layout antes de comprobar que las consultas funcionan fuera del dashboard.

Ejemplo 3: la alerta no se activa¶

Situación¶

La alerta de cinco errores HTTP 500 no se dispara.

Consulta de prueba¶

index=curso earliest=-5m latest=now
| eval status_num=tonumber(status)
| where status_num=500
| stats count as errores_500

Comprobaciones¶

¿Hay eventos nuevos?
¿El timestamp está dentro de los últimos cinco minutos?
¿El valor es realmente 500?
¿La alerta está habilitada?
¿La frecuencia es correcta?
¿El usuario puede ejecutar la alerta?
¿Existe throttling?
¿La acción está configurada?

Documentación esperada¶

La entrega debe indicar si la alerta:

se probó con eventos históricos;
se probó con eventos recientes;
se probó en tiempo real;
no pudo probarse por falta de datos;
necesita un archivo incremental.

Ejemplo 4: falta el campo de IP¶

Situación¶

El proyecto solicita identificar la IP con más errores, pero el dataset solo contiene:

timestamp,host,method,status,uri

Consulta¶

index=curso earliest=0 latest=now
| fieldsummary

Decisión correcta¶

Documentar:

El dataset no contiene una IP de origen. Por tanto, no se puede realizar un análisis fiable por cliente. Se utiliza un análisis alternativo por host y se propone añadir clientip en una futura versión de la fuente.

Consulta alternativa¶

index=curso earliest=0 latest=now
| eval status_num=tonumber(status)
| where status_num>=400
| stats count as errores by host
| sort - errores

16. Cómo citar los enlaces en los entregables¶

Cuando una fuente se utilice para justificar una decisión, registra:

número o nombre de referencia;
título;
enlace;
parte del proyecto relacionada;
fecha de consulta.

Ejemplo¶

La configuración de la entrada de monitorización se basó en la documentación
oficial de `inputs.conf`.

Referencia:
- Splunk, `inputs.conf`.
- https://help.splunk.com/en/data-management/splunk-enterprise-admin-manual/10.4/configuration-file-reference/10.4.0-configuration-file-reference/inputs.conf
- Consultada el: ____________________

No sustituir la prueba por una referencia¶

La documentación explica cómo debería funcionar una capacidad.

La práctica debe demostrar que funciona en la instancia del curso.

Por ejemplo:

una referencia puede explicar cómo crear una alerta;
la evidencia debe mostrar que la alerta se creó y se probó;
una referencia puede explicar timechart;
la evidencia debe mostrar una búsqueda ejecutada;
una referencia puede explicar roles;
la evidencia debe mostrar los permisos configurados.

17. Lista de comprobación de enlaces¶

Documentación oficial¶

Compatibilidad¶

El enlace corresponde con el producto utilizado.
La versión está documentada.
Se han revisado las diferencias de versión.
Se han comprobado los ejemplos en el laboratorio.
No se han copiado configuraciones sin validarlas.

Entrega¶

Las fuentes utilizadas están identificadas.
Los enlaces se pueden abrir.
La fecha de consulta está registrada.
Cada fuente tiene una utilidad concreta.
Las fuentes externas están contrastadas.
No se han incluido credenciales.
No se han incluido tokens privados.
Las capturas no exponen información sensible.

Enlaces¶

1. Información del entorno de referencia¶

2. Documentación oficial de Splunk¶

Splunk Enterprise Documentation¶

Splunk Help¶

Splunk Enterprise 10.4¶

Notas de versión¶

3. Búsqueda y lenguaje SPL¶

Search Manual¶

Search Reference¶

Comando stats¶

Comando eval¶

Comando where¶

Comando timechart¶

Comando fieldsummary¶

Búsqueda optimizada¶

4. Ingesta y entrada de datos¶

Get Data In¶

How Splunk Processes Data¶

Monitor Files and Directories¶

Source Types¶

Inputs¶

5. Índices y almacenamiento¶

About Indexes¶

Indexes.conf¶

Buenas prácticas para el índice del curso¶

Consultar varios índices¶

6. Dashboards y visualizaciones¶

Dashboards¶

Dashboard Studio¶

Classic Dashboards¶

Selección de visualizaciones¶

Ejemplo de panel de errores por código¶

Ejemplo de panel temporal¶

Buenas prácticas para dashboards¶

7. Alertas¶

About Alerts¶

Ejemplo de alerta del proyecto¶

Elementos que deben documentarse¶

Prueba histórica¶

Alertas y permisos¶

8. Usuarios, roles y seguridad¶

Role-Based User Access¶

Users and Roles¶

Define Roles and Capabilities¶

Knowledge Objects¶

Principio de mínimo privilegio¶

Revisar el contexto del usuario¶

Revisar objetos compartidos¶

9. API REST de Splunk¶

Splunk REST API Reference¶

Revisar entradas monitorizadas¶

Revisar índices¶

Revisar el usuario actual¶

10. Sistema operativo Ubuntu¶

Ubuntu Server Documentation¶

Systemd¶

Comandos utilizados en el laboratorio¶

Estado del servicio¶

Estado mediante Splunk¶

Versión instalada¶

Puertos abiertos¶

Permisos de una ruta¶

Permisos de un archivo¶

Qué comprobar en Ubuntu¶

11. Troubleshooting¶

Índice de troubleshooting¶

Diagnóstico mediante _internal¶

Problema: no aparecen eventos¶

Problema: el archivo existe, pero no aparece en Splunk¶

Problema: el timestamp no se reconoce¶

Problema: el campo no existe¶

Problema: la alerta no se dispara¶

12. Observabilidad y monitorización web¶

Temas externos recomendados¶

Indicadores habituales¶

Relación con el proyecto¶

13. Recursos externos recomendados¶

Tipos de recursos útiles¶

Criterios para seleccionar un recurso externo¶

Comando `stats`¶

Comando `eval`¶

Comando `where`¶

Comando `timechart`¶

Comando `fieldsummary`¶

Diagnóstico mediante `_internal`¶