Bluetab

an IBM Company

Blog

Cómo depurar una Lambda de AWS en local

by

Cómo depurar una Lambda de AWS en local

Bluetab

AWS Lambda es un servicio serverless mediante el que se puede ejecutar código sin necesidad de levantar ni administrar máquinas. Se paga solamente por el tiempo consumido en la ejecución (15 minutos como máximo).

El servicio dispone de un IDE simple, pero por su propia naturaleza no permite añadir puntos de ruptura para depurar el código. Seguro que algunos de vosotros os habéis visto en esta situación y habéis tenido que hacer uso de métodos poco ortodoxos como prints o ejecutar el código directamente en vuestra máquina, pero esto último no reproduce las condiciones reales de ejecución del servicio.

Para permitir depurar con fiabilidad desde nuestro propio PC, AWS pone a disposición SAM (Serverless Application Model).

Instalación

Los requisitos necesarios son (se ha usado Ubuntu 18.04 LTS):

  • Python (2.7 ó >= 3.6)
  • Docker
  • IDE que se pueda enlazar a un puerto de debug (en nuestro caso usamos VS Code)
  • awscli


Para instalar la CLI de AWS SAM desde AWS recomiendan brew tanto para Linux como macOS, pero en este caso se ha optado por hacerlo con pip por homogeneidad:

python3 -m pip install aws-sam-cli

Configuración y ejecución

1. Iniciamos un proyecto SAM

sam init
  • Por simplicidad se selecciona “AWS Quick Start Templates” para crear un proyecto a través de plantillas predefinidas
  • Se elige la opción 9 – python3.6 como el lenguaje del código que contendrá nuestra lambda
  • Se selecciona la plantilla de “Hello World Example»

En este momento ya tenemos nuestro proyecto creado en la ruta especificada:

  • /helloworld: app.py con el código Python a ejecutar y requirements.txt con sus dependencias
  • /events: events.json con ejemplo de evento a enviar a la lambda para su ejecución. En nuestro caso el trigger será un GET a la API a http://localhost:3000/hello
  • /tests : test unitario
  • template.yaml: plantilla con los recursos de AWS a desplegar en formato YAML de CloudFormation. En esta aplicación de ejemplo sería un API gateway + lamba y se emulará ese despliegue localmente

2. Se levanta la API en local y se hace un GET al endpoint

sam local start-api

Concretamente el endpoint de nuestro HelloWorld
será http://localhost:3000/hello Hacemos un GET

Y obtenemos la respuesta de la API

3. Añadimos la librería ptvsd (Python Tools for Visual Studio) para debugging a requirements.txt quedando como:

requests
ptvsd

4. Habilitamos el modo debug en el puerto 5890 haciendo uso del siguiente código en helloworld/app.py

import ptvsd

ptvsd.enable_attach(address=('0.0.0.0', 5890), redirect_output=True)
ptvsd.wait_for_attach()

Añadimos también en app.py dentro de la función lambda_handler varios prints para usar en la depuración

print('punto de ruptura')

print('siguiente línea')

print('continúa la ejecución')

return {
    "statusCode": 200,
    "body": json.dumps({
        "message": "hello world",
        # "location": ip.text.replace("\n", "")
    }),
}

5. Aplicamos los cambios realizados y construimos el contenedor

sam build --use-container

6. Configuramos el debugger de nuestro IDE

En VSCode se utiliza el fichero launch.json. Creamos en la ruta principal de nuestro proyecto la carpeta .vscode y dentro el fichero

{
  "version": "0.2.0",
  "configurations": [
      {
          "name": "SAM CLI Python Hello World",
          "type": "python",
          "request": "attach",
          "port": 5890,
          "host": "127.0.0.1",
          "pathMappings": [
              {
                  "localRoot": "${workspaceFolder}/hello_world",
                  "remoteRoot": "/var/task"
              }
          ]
      }
  ]
}

7. Establecemos un punto de ruptura en el código en nuestro IDE

8. Levantamos nuestra aplicación con la API en el puerto de debug

sam local start-api --debug-port 5890

9. Hacemos de nuevo un GET a la URL del endpoint http://localhost:3000/hello

10. Lanzamos la aplicación desde VSCode en modo debug, seleccionando la configuración creada en launch.json

Y ya estamos en modo debug, pudiendo avanzar desde nuestro punto de ruptura

Alternativa: Se puede hacer uso de events/event.json para lanzar la lambda a través de un evento definido por nosotros

En este caso lo modificamos incluyendo un solo parámetro de entrada:

{
   "numero": "1"
}
Y el código de nuestra función para hacer uso del evento:
print('punto de ruptura número: ' + event["numero"])
De esta manera, invocamos a través del evento en modo debug:
sam local invoke HelloWorldFunction -d 5890 -e events/event.json
Podemos ir depurando paso a paso, viendo como en este caso se hace uso del evento creado:
¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

¿Cuánto vale tu cliente?

by

¿Cuánto vale tu cliente?

Bluetab

Nuestro cliente es una multinacional referente del sector de la energía con inversiones en extracción, generación y distribución, con importante implantación en Europa y Latinoamérica. Actualmente está desarrollando iniciativas de inteligencia de negocio explotando sus datos con soluciones embebidas sobre plataformas cloud. 

El problema que tenía era gordo ya que, para generar cualquier caso de uso, había que consultar un sinnúmero de fuentes de información generadas manualmente por diversos departamentos esto incluye archivos de texto y hojas de cálculo, pero no solo eso, también había que echar mano de sistemas de información que van desde Oracle DB hasta Salesforce. 

«El problema que tenía era gordo ya que, para generar cualquier caso de uso, había que consultar un sin número de fuentes de información generadas manualmente.»

La solución estaba clara, había que concentrar toda la información necesaria en un solo lugar, de manera segura, disponible en todo momento, organizada y sobre todo, eficiente en costos. La decisión fue implementar un DataLake en la nube de AWS.

En la evolución del proyecto, el cliente está preocupado ante las vulnerabilidades de sus servidores locales donde ha tenido algunos problemas con la disponibilidad de sus servicios e incluso la intrusión de un virus informático, a lo que /bluetab propone migrar los procesos más críticos completamente a la nube, entre ellos un modelo de segmentación de clientes, desarrollado en R. 

Para segmentar la cartera de clientes se requiere de un ETL desarrollado en Python usando como DWH Amazon Redshift, donde además se ejecuta a demanda un clúster Big Data EMR con tareas desarrolladas en Scala para manejar grandes volúmenes de información de transacciones generadas de manera diaria. Los resultados del proceso que anteriormente eran alojados y explotados desde un servidor Microstrategy, ahora fueron desarrollados en reportes y dashboards usando Power BI.

«…el nuevo diseño de la arquitectura y la mejor gestión de los servicios cloud en su uso diario, nos permitió optimizar la facturación en la nube reduciendo en mas de un 50% el OPEX»

No solo logramos integrar un cúmulo importante de información de negocio en un repositorio centralizado y gobernado, sino que el nuevo diseño de la arquitectura y la mejor gestión de los servicios cloud es su uso diario, nos permitió optimizar la facturación en la nube reduciendo en más de un 50% el OPEX. Pero además este nuevo modelo permite acelerar el desarrollo de cualquier iniciativa que requiera hacer uso de estos datos, y con ello reducir el costo del proyecto

Ahora nuestro cliente quiere poner a prueba y aprovechar las herramientas que hemos puesto en sus manos para responder una pregunta más complicada ¿Cuánto valen mis clientes?…

Su modelo tradicional de segmentación en el negocio de distribución se basaba fundamentalmente en un análisis del histórico de pagos y del volumen de facturación. De esta manera predicen la posibilidad de impagos en nuevos servicios, y el valor potencial del cliente en términos de facturación. Todo ello cruzado con información de estados financieros conformaba aún un modelo con un amplio rango de mejora.

«En /bluetab tenemos experiencia en desarrollo de modelos analiticos que aseguren una aplicación edficiente y medible de los algoritmos más adecuados para cada problemática y cada set de datos»

En /bluetab tenemos experiencia en el desarrollo de modelos analíticos que aseguren una aplicación eficiente y medible de los algoritmos más adecuados para cada problemática y cada set de datos, pero en este momento el mercado aporta soluciones de modelos analíticos muy maduros que, con una mínima parametrización, permiten obtener buenos resultados acortando drásticamente el tiempo de desarrollo. De esta manera, echamos mano de un modelo ampliamente probado de CLV (Customer Lifetime Value) para ayudar a nuestro cliente a evaluar el potencial valor en el ciclo de vida de sus clientes.

En el nuevo escenario, a los datos de ingresos y gastos de los clientes, hemos incorporado variables como Costos de atención Postventa (como gestión de recobro, costes de resolución de incidencias en CC, costos de agentes intermediarios de facturación…), y costes de Logistica de Aprovisionamiento, pudiendo incluir datos sobre posicionamiento geográfico para costes de distribución, madurez del mercado en términos de market share, o cruzarlo con información que proporcionan diferentes fuentes del mercado. De esta manera nuestro cliente puede hacer estimaciones más ajustadas del valor de sus clientes actuales y potenciales, y realizar modelizaciones y predicción de rentabilidad de nuevos mercados o nuevos servicios.

El potencial beneficio en la aplicación de los modelos analíticos depende de aspectos menos “sexis” como son una consistente organización y gobierno en el back office de los datos, la calidad de los datos que aprovisionan el modelo, la puesta en marcha del modelo siguiendo las mejores prácticas DevOps y la constante comunicación con el cliente para asegurar el alineamiento con negocio y poder extraer/visualizar las conclusiones de valor de la información obtenida. Y en /bluetab creemos que esto sólo es posible con un conocimiento técnico experto y una profunda vocación de entendimiento del negocio de nuestros clientes.   

«El potencial beneficio en la aplicacion de los modelos analiticos solo es posible con un conocimiento técnico experto y una profunda vocación de entendimiento del negocio de nuestros clientes»

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

Deja un comentario

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Tenemos Plan B

by

Tenemos Plan B

Bluetab

El Reto Pelayo Vida patrocinado por /bluetab, siempre ha buscado lugares recónditos del planeta, localizaciones lejanas y paisajes extraordinarios, pero el mundo está viviendo una situación hasta ahora desconocida y ahora hay que velar por la seguridad de las expedicionarias. Para ello ha puesto en marcha un Plan B a la altura de las circunstancias:

Las expedicionarias partirán de Bilbao y en tres etapas, rodearán toda la península, pasando el Estrecho y parando en Málaga y Valencia para finalizar en Barcelona.

El Reto Pelayo Vida 2020 en números

millas naúticas
+ 0 mil
candidatas
0
campeona olímpica
0
de calado
0 m
pies de eslora
0
de manga
0 m

Un año más, en línea con nuestro Plan de Igualdad, los bluetabers, somos un apoyo vital para estas mujeres

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Detección de Fraude Bancario con aprendizaje automático II

by

Detencción de fraude bancario con aprendizaje automático II

Bluetab

¡Un modelo para pillarlos a todos !

La creación de modelos descriptivos y predictivos se basa en la estadística y el reconocimiento de patrones de grupos con características similares. Hemos creado una metodología que permite la detección de anomalías usando el comportamiento histórico de transacciones del canal ATM para una de las entidades financieras más importantes en Latam.

Mano a mano con el cliente y un grupo de estadistas y expertos en tecnología, hemos creado una herramienta para los procesos de auditoría que facilita la detección de anomalías en los frentes más importantes y accionables para el negocio. Desde problemas operativos, de disponibilidad, errores tecnológicos, hasta fraude interno o externo.

El canal de ATMs representa una área de negocio que se encuentra sometida a contacto directo con el público usuario, y es vulnerable por razones como la conectividad y fallas de hardware. El número de transacciones diarias de una red de más de 2000 cajeros involucra una cantidad enorme de indicadores y métricas registradas tanto de carácter tecnológico, como también operativo. Actualmente un grupo de auditores se da a la tarea de muestrear y analizar de manera manual este stream de datos para identificar riesgos sobre la operativa del canal ATM.

Las características de la operativa, hacen que la tarea de reconocer patrones sea diferente para cada ATM dado que la tecnología en cada unidad y el volumen de transacciones está influenciada por factores como el fenómeno estacional, la demografía e incluso el estatus económico de la zona. Para hacer frente a este reto /bluetab desarrolló un framework alrededor de Python y SQL para la segmentación de las tipologías más adecuadas conforme a criterios variables, y la detección de anomalías sobre un conjunto de más de 40 indicadores clave para la operativa del canal. Para ello se  involucraron modelos de aprendizaje no supervisado, y  series de tiempo que nos permiten identificar entre grupos de cajeros comparables y lograr una detección de anomalías más certera.

Los resultados de este framework, puramente matemáticos, fueron condensados y traducidos en métricas de vulnerabilidad manejables para el negocio, y que desarrollamos de la mano del usuario final en Qliksense. De esta manera pusimos en manos del cliente un entorno de análisis que cubre todos los aspectos importantes de la operativa pero que además permite incorporar otras casuística a demanda.

Ahora los auditores pueden hacer análisis sobre meses de información que considera las situación temporal del mercado, la posición geográfica o las características tecnológicas y transaccionales, donde antes solo tenían capacidad para analizar muestras.

Trabajamos con nuestro cliente para impulsar iniciativas que permitan incorporar la tecnología y hacer más eficiente la operación y agilizar el tiempo de respuesta ante cualquier incidencia.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Detección de Fraude Bancario con aprendizaje automático

by

Detencción de fraude bancario con aprendizaje automático

Bluetab

El sector financiero se encuentra en la actualidad sumergido en una lucha contra el fraude bancario siendo uno de sus mayores retos. En el 2018, la banca española notificó un aumento del 17,7% de las reclamaciones producidas por cobros o transacciones indebidas con respecto al año anterior y sólo en 2017 hubo más de 123.064 fraudes online a empresas y particulares.

La banca española está encarando la batalla contra el fraude desde un punto de vista tecnoló-gico. Actualmente en pleno proceso de digitaliza-ción, con inversiones que rondan los 4.000 millo-nes de euros anuales, está dedicando sus esfuer-zos en la adopción de nuevas tecnologías como el Big Data y la Inteligencia Artificial. Con estas tecnologías se pretende mejorar y automatizar distintos procesos donde se incluye la gestión y detección del fraude.

En /bluetab estamos llevando a cabo distintas iniciativas dentro del marco tecnológico de Big Data e Inteligencia Artificial en el sector finan-ciero. En el marco de nuestras iniciativas de “Advanced Analytics & Machine Learning” nos encontramos actualmente colaborando en proyectos de Seguridad y Fraude donde, gracias al uso del Big Data y la Inteligencia Artifi-cial, somos capaces de ayudar a nuestros clien-tes a crear modelos predictivos más precisos.

Y, ¿cómo el aprendizaje automático puede ayudar a prevenir el fraude bancario?. Poniendo foco en las colaboraciones realizadas dentro del área de Fraude, /bluetab afronta este tipo de iniciativas partiendo de una serie de transferencias identificadas como fraude y de un set de datos con las sesiones de los usuarios en la banca electrónica. El reto consiste en generar un modelo capaz de predecir cuándo una sesión puede ser fraudulenta poniendo el “target” en los falsos positivos y negativos que el modelo pueda producir.

La comprensión del negocio y de los datos es de gran importancia para realizar una correcta modelación

Para la resolución de este tipo de retos tecnológicos, hemos observado cómo el uso de una meto-dología es de vital importancia para poder encarar estos retos. En /bluetab hacemos uso de una adaptación in-house y “ad-hoc” para Banca de la metodología CRISP-DM en la cual distinguimos las siguientes fases:

  • Comprensión del negocio
  • Comprensión de los datos
  • Calidad de los datos
  • Construcción de predictores inteligentes
  • Modelación


Consideramos que en los proyectos de detección de Fraude Online la comprensión del negocio y de los datos es de gran importancia para realizar una correcta modelación. Un buen análisis de los datos nos permite poder observar cómo éstos están relacionados con la variable objetivo (el fraude), así como otros aspectos estadísticos (distribución de los datos, búsqueda de outliers, etc.) de no menor importancia. En estos análisis se puede observar la existencia de variables con gran capacidad predictiva las cuales denominamos “variables diamante”. Atributos como: el número de visitas a la web, el dispositivo utilizado para la conexión, el sistema operativo o el navegador utilizado para la sesión (entre otras), suelen encontrarse fuertemente relacionadas con el fraude bancario. Además, el estudio de estas variables nos dice que, de manera individual, pueden llegar a reunir más del 90% de las transacciones fraudulentas. Es decir, el análisis y la comprensión del negocio y los datos, permite evaluar la mejor forma de plantear una solución sin vernos perdidos en un mar de datos.

Una vez se tiene el conocimiento del negocio y de los datos y tras haber obtenido aquellas varia-bles con mayor poder predictivo, es imprescindible contar con herramientas y procesos que aseguren la calidad de estas variables. Es indispensable realizar los entrenamiento de los modelos predictivos con variables y datos históricos fiables. Un entrenamiento con variables de baja calidad podría dar lugar a modelos erráticos con gran impacto dentro del negocio.

Tras asegurar la fiabilidad de las variables predictoras seleccionadas, la siguiente etapa pasa por construir variables predictoras inteligentes. Estas variables seleccionadas en los pasos anteriores, aún teniendo una fuerte relación con la variable a predecir (target) puede provocar ciertos problemas de comportamiento a la hora de realizar la modelación, es por eso que es nece-sario un paso de preparación de los datos. Esta preparación de datos pasa por realizar ciertas adaptaciones a las variables para poder ser utilizada dentro del algoritmo, como puede ser el tratamiento de nulos o el tratamiento de variables categóricas. Adicionalmente, se debe realizar un tratamiento correcto de los outliers identificados en los pasos previos, para no incluir información que pueda distorsionar el modelo.

De la misma manera, con el objetivo de “afinar” el resultado, es de vital importancia aplicar distintas transformaciones a las variables para mejorar el valor predictivo del modelo. Transformaciones matemáticas básicas como la exponencial, la logarítmica o la estandarización, junto con transformaciones más complejas como la WoE permiten poder mejorar de manera nota-ble la calidad de los modelos predictivos gracias al uso de variables más trabajadas facilitando la tarea al modelo.

Por último, la etapa de modelación se centra en enfrentar distintos tipos de algoritmos con distintas configuraciones de hiperparámetros para obtener aquél modelo que genere una mejor predicción. Aquí es donde herramientas como Spark nos ayudan en gran medida, al poder realizar entrenamientos de distintos algoritmos y configuraciones de manera rápida, gracias a la programación distribuida.

Para la sostenibilidad de su aplicación y evitar la obsolescencia del modelo, esta metodología se debe ir siguiendo de manera mensual en cada caso de uso y más a la hora de encarar una iniciativa como es el fraude bancario. Esto se debe a que pueden aparecer nuevas formas de fraude que no estén contempladas en los modelos entrenados. Por ello es importante tener entendimiento y seleccionar adecuadamente las variables con las que reentrenar los modelos, para que no se queden obsoletos con el tiempo, lo que podría perjudicar gravemente al negocio.

En definitiva, una buena metodología de trabajo es vital a la hora de enfrentarse a problemas dentro del mundo de la Inteligencia Artificial y Advanced Analytics, siendo esenciales las fases de comprensión del negocio y de los datos. Siendo un “must” en la actualidad el disponer de herramientas internas especializadas que permitan ejecutar este tipo de proyectos en pocas semanas, generando quick wins en nues-tros clientes y sus negocio

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

Espiando a tu kubernetes con kubewatch

by

Espiando a tu Kubernetes con Kubewatch

Bluetab

Desde la Práctica Cloud queremos impulsar la adopción de la nube como forma de trabajo en el mundo de IT. Para ayudar en esta tarea, vamos a publicar multitud de artículos de buenas prácticas y casos de uso, otros hablarán aquellos servicios clave dentro de la nube.

En esta ocasión hablaremos de Kubewatch.

¿Qué es Kubewath?

Kubewatch es una utilidad desarrollada por Bitnami Labs que permite el envío de notificaciones a distintos sistemas de comunicación.

Los webhooks soportados son:

  • Slack
  • Hipchat
  • Mattermost
  • Flock
  • Webhook
  • Smtp

Integración de kubewatch con Slack

Las imágenes disponibles están publicadas en el GitHub de bitnami/kubewatch

Si queréis, podéis descargaros la última versión para probarla en vuestro entorno local:

$ docker pull bitnami/kubewatch

Una vez dentro del contenedor podéis jugar con las opciones:

$ kubewatch -h

Kubewatch: A watcher for Kubernetes

kubewatch is a Kubernetes watcher that publishes notifications
to Slack/hipchat/mattermost/flock channels. It watches the cluster
for resource changes and notifies them through webhooks.

supported webhooks:
 - slack
 - hipchat
 - mattermost
 - flock
 - webhook
 - smtp

Usage:
  kubewatch [flags]
  kubewatch [command]

Available Commands:
  config      modify kubewatch configuration
  resource    manage resources to be watched
  version     print version

Flags:
  -h, --help   help for kubewatch

Use "kubewatch [command] --help" for more information about a command.

¿De qué tipos de recursos podemos obtener notificaciones?

¿Cuándo recibiremos una notificación?

En cuanto haya una acción sobre algún objeto de kubernetes, así como creación, destrucción o actualización.

Configuración

En primer lugar, crearemos un canal de slack y le asociaremos un webhook. Para ello, iremos a la sección de Apps de Slack, buscaremos “Incoming WebHooks” y pulsaremos “Add to Slack”:

En el caso de no tener aún un canal creado para este propósito daremos de alta uno nuevo:

En este ejemplo, el canal a crear se llamará “k8s-notifications”. Posteriormente debemos configurar el webhook, yendo para ello al panel de “Incoming WebHooks” y añadiendo una nueva configuración donde tendremos que seleccionar el nombre del canal al que queremos enviar notificaciones. Una vez seleccionado, la configuración nos devolverá una «Webhook URL» que será la que utilicemos para configurar Kubewatch. Opcionalmente, tenemos la posibilidad de seleccionar el icono (opción «Customize Icon») con el que visualizaremos la recepción de eventos y el nombre con el que llegarán (opción “Customize Name”).

En este punto ya estamos listos para configurar los recursos de kubernetes. En el GitHub de Kubewatch tenemos algunos ejemplos de manifiestos y también la opción de instalación por Helm. Sin embargo, aquí construiremos los nuestros propios.

En primer lugar, crearemos un fichero “kubewatch-configmap.yml” con el ConfigMap que servirá para configurar el contenedor de kubewatch:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubewatch
data:
  .kubewatch.yaml: |
    handler:
      webhook:
        url: https://hooks.slack.com/services/<your_webhook>
    resource:
      deployment: true
      replicationcontroller: true
      replicaset: false
      daemonset: true
      services: true
      pod: false
      job: false
      secret: true
      configmap: true
      persistentvolume: true
      namespace: false

Simplemente tendremos que activar con “true” o desactivar con «false» los tipos de recursos sobre los que queremos recibir notificaciones. Asimismo, establecemos la url del Incomming Webhook que dimos de alta previamente.

Ahora, para que nuestro contenedor tenga acceso a los recursos de kubernetes a través de su api vamos a dar de alta el fichero “kubewatch-service-account.yml” con un Service Account, un Cluster Role y un Cluster Role Binding:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: kubewatch
rules:
- apiGroups: ["*"]
  resources: ["pods", "pods/exec", "replicationcontrollers", "namespaces", "deployments", "deployments/scale", "services", "daemonsets", "secrets", "replicasets", "persistentvolumes"]
  verbs: ["get", "watch", "list"]
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubewatch
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: kubewatch
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubewatch
subjects:
  - kind: ServiceAccount
    name: kubewatch
    namespace: default

Por último, crearemos un fichero “kubewatch.yml” para desplegar la aplicación:

apiVersion: v1
kind: Pod
metadata:
  name: kubewatch
  namespace: default
spec:
  serviceAccountName: kubewatch
  containers:
  - image: bitnami/kubewatch:0.0.4
    imagePullPolicy: Always
    name: kubewatch
    envFrom:
      - configMapRef:
          name: kubewatch
    volumeMounts:
    - name: config-volume
      mountPath: /opt/bitnami/kubewatch/.kubewatch.yaml
      subPath: .kubewatch.yaml
  - image: bitnami/kubectl:1.16.3
    args:
      - proxy
      - "-p"
      - "8080"
    name: proxy
    imagePullPolicy: Always
  restartPolicy: Always
  volumes:
  - name: config-volume
    configMap:
      name: kubewatch
      defaultMode: 0755

Vemos que el valor de la clave “mountPath” será la ruta del fichero donde se escribirá la configuración de nuestro ConfigMap dentro del contenedor (/opt/bitnami/kubewatch/.kubewatch.yaml). Podemos ampliar aquí la información sobre cómo montar configuraciones en kubernetes. En este ejemplo, vemos que nuestro despliegue del aplicativo será a través de un único pod. Evidentemente, en un sistema productivo tendríamos que definir un Deployment con el número de réplicas que consideremos convenientes para tenerlo así siempre activo, aun en caso de pérdida del pod.

Una vez listos los manifiestos vamos a aplicarlos a nuestro clúster:

$ kubectl apply  -f kubewatch-configmap.yml -f kubewatch-service-account.yml -f kubewatch.yml

En unos pocos segundos tendremos listo el servicio:

$ kubectl get pods |grep -w kubewatch

kubewatch                                  2/2     Running     0          1m

El pod de kubewatch tiene asociado dos contenedores: kubewatch y kube-proxy, este último para atacar a la API.

$   kubectl get pod kubewatch  -o jsonpath='{.spec.containers[*].name}'

kubewatch proxy

Verificamos a través de los logs que ambos contenedores han levantado correctamente y sin mensajes de error:

$ kubectl logs kubewatch kubewatch

==> Config file exists...
level=info msg="Starting kubewatch controller" pkg=kubewatch-daemonset
level=info msg="Starting kubewatch controller" pkg=kubewatch-service
level=info msg="Starting kubewatch controller" pkg="kubewatch-replication controller"
level=info msg="Starting kubewatch controller" pkg="kubewatch-persistent volume"
level=info msg="Starting kubewatch controller" pkg=kubewatch-secret
level=info msg="Starting kubewatch controller" pkg=kubewatch-deployment
level=info msg="Starting kubewatch controller" pkg=kubewatch-namespace
... 
$ kubectl logs kubewatch proxy

Starting to serve on 127.0.0.1:8080

Podríamos igualmente acceder al contenedor de kubewatch para probar la cli, ver la configuración, etcétera:

$  kubectl exec -it kubewatch -c kubewatch /bin/bash

¡Ya tenemos listo nuestro notificador de eventos!

Ahora toca probar. Utilizaremos, por ejemplo, la creación de un deployment para testear el correcto funcionamiento:

$ kubectl create deployment nginx-testing --image=nginx
$ kubectl logs -f  kubewatch kubewatch

level=info msg="Processing update to deployment: default/nginx-testing" pkg=kubewatch-deployment

Los logs ya nos avisan que se ha detectado el nuevo evento, así que vamos a nuestro canal de slack para verificarlo:

¡El evento ha sido notificado correctamente!

Ya podemos eliminar el deployment de prueba:

$ kubectl delete deploy nginx-testing

Conclusiones

Evidentemente, Kubewatch no suple a los sistemas básicos de alerta y monitorización que todo orquestador productivo debe mantener, pero nos proporciona una manera fácil y eficaz de ampliar nuestro control sobre la creación y modificación de los recursos en kubernetes. En este caso de ejemplo, hemos realizado una configuración de kubewatch transversal a todo el clúster, “espiando” todo tipo de eventos, algunos quizá inservibles si mantenemos una plataforma como servicio, pues nos enteraríamos de cada uno de los pods creados, eliminados o actualizados por cada equipo de desarrollo en su propio namespace, lo cual es usual, legítimo y no aporta valor. Quizá sea más conveniente filtrar por los namespaces sobre cual queremos recibir notificaciones, como por ejemplo de kube-system, que es donde albergaremos generalmente nuestros servicios administrativos y donde solo los administradores deben tener acceso. En ese caso, simplemente tendremos que especificar el namespace en nuestro ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: kubewatch
data:
  .kubewatch.yaml: |
    namespace: "kube-system"
    handler:
      webhook:
        url: https://hooks.slack.com/services/<your_webhook>
    resource:
      deployment: true
      replicationcontroller: true
      replicaset: false

Otra utilidad interesante puede ser “escuchar” a nuestro clúster tras un ajuste signicativo de la configuración como, por ejemplo, de nuestra estrategia de autoescalado, herramientas de integración, etcétera, pues siempre nos notificará los scale up y scale down, pudiendo ser interesante sobre todo en un momento inicial. En definitiva, Kubewatch amplía el control sobre los clústeres, siendo nosotros quienes decidamos el alcance que le damos. En sucesivos artículos veremos cómo gestionar los logs y las métricas de forma productiva.

¿Quieres saber más de lo que ofrecemos y ver otros casos de éxito?
DESCUBRE BLUETAB

SOLUCIONES, SOMOS EXPERTOS

DATA STRATEGY
DATA FABRIC
AUGMENTED ANALYTICS

Te puede interesar

© 2025 Bluetab Solutions Group, SL. All rights reserved.