<![CDATA[Category: java | Jetoile]]>2018-10-28T18:01:31+01:00https://blog.jetoile.fr/Octopress<![CDATA[Template de projets REST]]>2015-10-07T17:33:08+02:00https://blog.jetoile.fr/2015/10/template-de-projets-rest
Il y a déjà un long moment, j'avais posté une série d'article expliquant comment il était possible de faire des web service de type REST de manière simple via RestEasy-Netty ou via Undertow.
Dans la continuité de cette course au plus léger, je me suis dit que cela pouvait être intéressant de faire une petite étude un peu plus exhaustive des solutions légères qui existaient.
L'objectif étant extraire une sorte de bench un peu naïf et un peu out of the box. Parmi les solutions retenues, il y a :
Resteasy-Netty
Resteasy-Undertow
Restlet
SpringBoot
Resteasy sur Tomcat en utilisant ses connecteurs NIO
Resteasy sur Jetty
Cette article est là pour restituer mes résultats…
En fait, non… j'ai menti puisque je ne ferai aucun retour mais que je donnerai seulement le lien vers mon github où il est possible de trouver ces bootstrap de projets…
En effet, faire un bench est dangereux et complexe surtout quand toutes les implémentations ne sont pas maitrisées et qu'un tuning de ces dernières peut grandement modifier le résultat.
En outre, avoir un service exhaustif (autre que un simple helloword) qui est représentatif d'une vrai application et qui ne fait pas que taper dans le cache de la JVM ou de l'OS est plus complexe qu'écrire un simple sample.
Enfin, par manque de moyen (2 ordinateurs reliés par un wifi capricieux et par flemme de me monter des environnements plus représentatifs), je n'ai pu obtenir de résultats fiables…
Aussi, ci-joint les repos où il est possible de trouver le code (qui se veut ultra simple et qui a été fait sans chercher l'optimisation et sur un coin de table donc si des bourdes ont été faites, je m'en excuse…) :
Ainsi, si le coeur vous en dit, vous pourrez vous faire vous même une idée de qui est le plus fort… et même comparer avec vos solutions maisons… ;)
Allez, et parce que je suis sympa, je mets quand même le rapport Gatling obtenu suite à 1 seul tir en local. Je laisse le lecteur se faire une idée… ou pas…
Voilà un article un peu facile et qui n'apporte pas grand chose mais je trouvais qu'il était toujours intéressant pour les lecteurs curieux d'avoir la possibilité de voir différentes implementations…
]]><![CDATA[Undertow pour booster vos services REST]]>2015-06-23T14:51:56+02:00https://blog.jetoile.fr/2015/06/undertow-pour-booster-vos-services-rest
Il y a quelques temps, j'avais fait une série d'articles sur resteasy-netty et resteasy-netty4.
Cette article repart du même besoin, à savoir disposer d'une stack légère pour réaliser un service REST, mais en utilisant Undertow plutôt que Resteasy-Netty.
Au niveau des besoins, ils seront identiques ie. :
utiliser JAX-RS,
intégrer Swagger,
intégrer Jolokia,
générer un livrable autoporteur.
RestEasy-Netty, même s'il existe de nombreux points d'entrée, demande quelques phases de hack (gestion du crossover domain par exemple) et dispose d'un mécanisme un peu limité concernant la partie sécurité.
En outre, l'absence du mécanisme de Servlet reste un peu embêtant pour mettre en place certaines features comme le MDC ( Mapped Diagnostic Context ) bien pratique lorsque l'on est dans une architecture type microservice.
Comme je l'ai déjà indiqué dans les autres posts, l'objectif est seulement de montrer comme il peut être simple d'exposer un service REST à l'aide d'Undertow. Pour ce faire, un simple service sera exposé et il consistera à répèter ce qu’on lui demande…
A titre informatif, les versions des différentes librairies qui sont utilisés dans les exemples de code ci-dessous sont les suivantes (au format gradle pour gagner de la place) :
```text
Concernant la version des différentes dépendances, on constate que ce n'est pas swagger2 qui est utilisé en raison d'une incapacité de ma part à l'intégrer… :‘(
Implémentation du service REST
Le mise en place du service REST basé sur JAX-RS est on ne peut plus trivial… et la classe ci-dessous fait humblement l’affaire :
```java
@Api(value = “/sample”,
description = "the sample api")
@Path(“/sample”)
@RolesAllowed(“admin”)
public class SimpleService {
private final static Logger log = LoggerFactory.getLogger(SimpleService.class);
@GET
@Path("/say/{msg}")
@Produces(MediaType.APPLICATION_JSON)
@ApiOperation(value = "repeat the word",
notes = "response the word",
response = DtoResponse.class)
@ApiResponses(value = {@ApiResponse(code = 500, message = "Internal server error")})
public Response sayHello(@PathParam("msg") String message) {
log.info("sample log");
final Timer timer = Main.metricRegistry.timer(name(SimpleService.class, "say-service"));
final Timer.Context context = timer.time();
try {
DtoResponse response = new DtoResponse();
try {
response.setMessage(message);
response.setTime(LocalDateTime.now());
} catch (Exception e) {
log.error("internal error: {}", e);
return Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
}
return Response.ok(response).build();
} finally {
if (context != null) context.stop();
}
}
}
Coté du DTO, il est le suivant :
java
@XmlRootElement
public class DtoResponse {
private String message;
private LocalDateTime time;
public DtoResponse() {
}
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
public LocalDateTime getTime() {
return time;
}
public void setTime(LocalDateTime time) {
this.time = time;
}
}
```
On remarquera l'utilisation de Java8 pour la gestion du temps plutôt que Joda-Time.
En outre, concernant les annotations Swagger et l'utilisation de metrics, nous y reviendrons plus tard.
Concernant le message de log, de même, nous y reviendrons plus tard avec l'intégration d'un MDC pour les logs.
Mise en oeuvre avec Undertow
Mettre en place Resteasy avec Undertow est très simple, d’après la documnentation, il suffit de faire :
```java
SimpleService simpleService = new SimpleService();
ResteasyDeployment deployment = new ResteasyDeployment();
deployment.setResources(Arrays.
int port = config.getInt(“undertow.port”, TestPortProvider.getPort());
String host = config.getString(“undertow.host”, String.valueOf(TestPortProvider.getHost()));
System.setProperty(“org.jboss.resteasy.port”, String.valueOf(TestPortProvider.getPort());
System.setProperty(“org.jboss.resteasy.host”, String.valueOf(TestPortProvider.getHost());
UndertowJaxrsServer server = new UndertowJaxrsServer();
On y constate que pour ajouter un service, il suffit juste de déclarer la classe implémentant JAX-RS via la méthode setResources() sur l’instance de ResteasyDeployment fournit au serveur UndertowJaxrsServer :
Et voilà! On dispose désormais d’un programme exécutable qui démarre un serveur REST basé sur Undertow.
Par contre, il semble que le service ne rende pas vraiment ce que l'on voulait :
bash
curl 'http://localhost:8081/sample/say/<message>'
Concernant l'intégration de Metrics, pas grand chose de nouveau et donc pas grand chose à dire ;–)
Déclarer le registry :
java
metricRegistry = new MetricRegistry();
final JmxReporter reporter = JmxReporter.forRegistry(metricRegistry).build();
reporter.start();
Et utiliser le dans vos classes :
```java
final Timer timer = Main.metricRegistry.timer(name(SimpleService.class, “say-service”));
final Timer.Context context = timer.time();
try {
...
} finally {
if (context != null) context.stop();
}
```
Intégration de la sécurité
Undertow permet une bien meilleur intégration de la sécurité que RestEasy-Netty. En effet, grâce au mécanisme de Servlet, il est possible de bénéficier de toute la puissance des conteneurs de Servlets.
Du coté du serveur Undertow, il suffit donc de définir un ServletIdentityManager et de lui fournir un LoginConfig :
```java
deployment.setSecurityEnabled(true);
ServletIdentityManager identityManager = new ServletIdentityManager();
identityManager.addUser(“khanh”, “khanh”, “admin”);
où :
```java
public class ServletIdentityManager implements IdentityManager {
private static final Charset UTF_8 = Charset.forName("UTF-8");
private final Map<String, UserAccount> users = new HashMap<>();
public void addUser(final String name, final String password, final String... roles) {
UserAccount user = new UserAccount();
user.name = name;
user.password = password.toCharArray();
user.roles = new HashSet<>(Arrays.asList(roles));
users.put(name, user);
}
@Override
public Account verify(Account account) {
// Just re-use the existing account.
return account;
}
@Override
public Account verify(String id, Credential credential) {
Account account = users.get(id);
if (account != null && verifyCredential(account, credential)) {
return account;
}
return null;
}
@Override
public Account verify(Credential credential) {
return null;
}
private boolean verifyCredential(Account account, Credential credential) {
// This approach should never be copied in a realm IdentityManager.
if (account instanceof UserAccount) {
if (credential instanceof PasswordCredential) {
char[] expectedPassword = ((UserAccount) account).password;
char[] suppliedPassword = ((PasswordCredential) credential).getPassword();
return Arrays.equals(expectedPassword, suppliedPassword);
} else if (credential instanceof DigestCredential) {
DigestCredential digCred = (DigestCredential) credential;
MessageDigest digest = null;
try {
digest = digCred.getAlgorithm().getMessageDigest();
digest.update(account.getPrincipal().getName().getBytes(UTF_8));
digest.update((byte) ':');
digest.update(digCred.getRealm().getBytes(UTF_8));
digest.update((byte) ':');
char[] expectedPassword = ((UserAccount) account).password;
digest.update(new String(expectedPassword).getBytes(UTF_8));
return digCred.verifyHA1(HexConverter.convertToHexBytes(digest.digest()));
} catch (NoSuchAlgorithmException e) {
throw new IllegalStateException("Unsupported Algorithm", e);
} finally {
digest.reset();
}
}
}
return false;
}
private static class UserAccount implements Account {
// In no way whatsoever should a class like this be considered a good idea for a real IdentityManager implementation,
// this is for testing only.
String name;
char[] password;
Set<String> roles;
private final Principal principal = new Principal() {
@Override
public String getName() {
return name;
}
};
@Override
public Principal getPrincipal() {
return principal;
}
@Override
public Set<String> getRoles() {
return roles;
}
}
}
```
Il s'agit ici d'une Basic Authentification mais il est bien sûr possible d'en mettre en place d'autre.
Coté autorisation, il est alors possible de bénéficier de l'annotation @RolesAllowed de JAX-RS :
java
@Path("/sample")
@RolesAllowed("admin")
public class SimpleService {
...
}
Intégration d'un MDC
Concernant la mise en place d'un MDC (Mapped Diagnostic Context), le fait de bénéficier du mécanisme de Filter des Servlets rend la chose beaucoup plus simple.
En effet, une fois la couche sécurité branchée, il suffit de récupérer le UserPrincipal dans la requête et l'enregistrer dans le MDC.
La déclaration des Filters se fait de la manière suivante pour Undertow :
```java
FilterInfo mdcFilter = new FilterInfo(“MDCFilter”, MDCServletFilter.class);
deploymentInfo.addFilter(mdcFilter);
deploymentInfo.addFilterUrlMapping(“MDCFilter”, “*”, DispatcherType.REQUEST);
Avec le filter ci-dessous :
```java
public class MDCServletFilter implements Filter {
private final String USER_KEY = "username";
public void destroy() {
}
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
boolean successfulRegistration = false;
HttpServletRequest req = (HttpServletRequest) request;
Principal principal = req.getUserPrincipal();
// Please note that we could have also used a cookie to
// retrieve the user name
if (principal != null) {
String username = principal.getName();
successfulRegistration = registerUsername(username);
}
try {
chain.doFilter(request, response);
} finally {
if (successfulRegistration) {
MDC.remove(USER_KEY);
}
}
}
public void init(FilterConfig arg0) throws ServletException {
}
/**
* Register the user in the MDC under USER_KEY.
*
* @param username
* @return true id the user can be successfully registered
*/
private boolean registerUsername(String username) {
if (username != null && username.trim().length() > 0) {
MDC.put(USER_KEY, username);
return true;
}
return false;
}
}
Ainsi, disposer d'un MDC permet d'ajouter automatiquement des informations dans les logs :
xml
On obtient alors bien les logs voulues :
text
17:15:11.466 INFO f.j.sample.service.SimpleService 127.0.0.1 /sample/say/<message> - C:khanh - sample log
Intégration de Jolokia
Coté Jolokia, pas grand chose à ajouter par rapport à ma série d'article précédent…
```java
try {
JolokiaServerConfig config = new JolokiaServerConfig(new HashMap<String, String>());
JolokiaServer jolokiaServer = new JolokiaServer(config, true);
jolokiaServer.start();
} catch (Exception e) {
LOGGER.error("unable to start jolokia server", e);
}
```
Intégration de Swagger
Concernant l'intégration de Swagger, le fait de disposer des Filter de Servlet permet de n'avoir pas à faire de hack immonde pour gérer le CORS (cf. article précédent) : il suffit de déclarer un Filter dans Undertow qui a, en outre, la chance d'exister :
```java
CorsFilter filter = new CorsFilter();
filter.setAllowedMethods(“GET,POST,PUT,DELETE,OPTIONS”);
filter.setAllowedHeaders(“X-Requested-With, Content-Type, Content-Length, Authorization”);
filter.getAllowedOrigins().add(“*”);
Branchement des plugins Maven Appassembler et Assembly
Coté génération du livrable, encore une fois, pas grand chose à ajouter par rapport à mon précédent article : l'utilisation des plugins assembly et appassembler est identique.
Conclusion
On avait vu dans les articles précédents que RestEasy-Netty était une solution intéressante pour la simplicité de sa mise en oeuvre ainsi que pour le faible overhead.
Cependant, certaines intégrations ressemblaient plus à du hack qu'à une solution configurable.
Undertow (enfin pour être plus précis RestEasy-Undertow) pour sa part offre la même simplicité que RestEasy-Netty mais il permet en plus de s'intégrer avec beaucoup d'autres choses et le fait de retrouver le mécanisme de Filter facilite énormément les choses (par exemple, je ne suis pas sûr que bénéficier du MDC avec RestEasy-Netty ait été aussi simple).
Coté performance, je reviendrai dessus dans un autre article mais je peux déjà dire que la solution RestEasy-Undertow n'a rien à envier à RestEasy-Netty.
]]><![CDATA[Breizhcamp 2014 - Présentations en ligne]]>2014-06-12T08:28:38+02:00https://blog.jetoile.fr/2014/06/breizhcamp-2014-presentation-en-ligne
Pour ceux qui auraient manqué l'information, le BreizhCamp s'est déroulé en mai dernier et j'y avais la chance d'y présenter un talk sur un retour d'expérience concernant le passage à l'échelle d'un SI afin de lui permettre de supporter 4 millions d'utilisateurs.
Le synopsis était le suivant :
De 20 000 à 4 millions d'utilisateurs
Pour ce faire, il a été nécessaire de revoir certaines parties du SI afin de pouvoir stocker en masse les données des utilisateurs mais également afin d'être capable de les traiter.
Ce retour d'expérience montrera comment, avec une approche et des technologies simples, il a été possible de revoir la façon de faire et comment il a été proposé de traiter le sujet.
Il montrera également les pistes qui ont été étudiées et les solutions qui ont été retenues.
Les différents points qui seront abordés seront : Cassandra, REST, Netty, Spring Integration, Jolokia, Metrics saupoudré d'un peu de “Big Data”.
Encore une fois, je remercie la team pour :
l'organisation au top,
pour l'ambiance qu'ils ont su apporter à cette conférence,
mais également pour leur réactivité quant à mettre en ligne les vidéo des différents talk (sur YouTube mais également sur Parleys)
Du coup, vu que la vidéo de mon talk a été processée, j'en profite pour mettre le lien (désolé si je n'arrête pas de danser et désolé pour l'absence de démo dûe à mon ordinateur capricieux…) :
]]><![CDATA[Lecture et traitement de fichiers : comment faire simple?]]>2014-04-10T14:15:44+02:00https://blog.jetoile.fr/2014/04/lecture-et-traitement-de-fichiers-comment-faire-simple
De nombreuses applications ou systèmes d'informations nécessitent le chargement de données issues de fichiers.
Bien souvent, cet import est exécuté par batch, mais il peut aussi être intéressant de faire cet import au fil de l'eau.
En outre, bien souvent, les fichiers à importer sont, soient nombreux, soient volumineux. Du coup, écrire un code simple et fiable peut devenir plus ardu que ce qu'il n'y parait. Si, de plus, on veut ajouter des logs parlant (c'est à dire avec, au minimum, le temps de traitement d'un fichier et son nom), cela a tendance a rajouter du bruit au code. Sans oublier que lire un fichier est bien mais que, souvent, un traitement est effectué dessus…
Enfin, lors d'une forte volumétrie, une scalabilité horizontale peut être intéressante surtout dans le contexte actuel où la quantité d'information vient à exploser.
Cet article parlera donc de la problématique d'import de fichiers dans une application en s'appuyant sur des framework comme Spring Batch ou Spring Integration. Le mot d'ordre sera de le faire le plus simplement possible en s'appuyant au maximum sur ces framework.
Solution à base de batch
Ecrire un batch permettant de traiter des fichiers peut sembler simple mais lorsque le nombre de ces derniers vient à augmenter ou lorsque la taille des fichiers est volumineux, il arrive souvent que des bugs apparaissent. En outre, il convient alors de gérer manuellement les logs ainsi que la partie supervision.
Pour répondre à ce besoin, il est peut être avantageux d'utiliser Spring Batch (ou une autre implémentation de la JSR 352).
ndlr : je ne présenterai pas le fonctionnement de Spring Batch à base de Job et Step puisque cela se trouve très facilement dans les documents officiels, livres ou articles de blog et je mettrai plutôt l'accent sur la faisabilité de tel ou tel chose.
Spring Batch offre nativement la possibilité de traiter les fichiers par chunk via :
FlatFileItemReader qui permet de lire un fichier plat ligne par ligne et où chaque ligne dispose de la même information (il est également possible de traiter des types de lignes différentes issues du même fichier avec PatternMatchingCompositeLineMapper).
StaxEventItemReader pour lire fichiers xml composés de format de fragments identiques :
Généralement, il est nécessaire de préciser le nom du fichier à traiter mais il est également possible d'en traiter plusieurs de même type dans la même Step via la classe MultiResourceItemReader.
Ainsi, on constate que Spring Batch offre nativement la possibilité de traiter des fichiers volumineux en les découpant par chunk.
De même, il offre nativement la possibilité de passer sur du traitement parallèle.
Concernant la partie supervision, vu que l'on est dans un environnement Spring, on bénéficie, bien sûr, de toute la partie JMX.
Pour la partie gestion des erreurs, Spring Batch permet de les gérer de manière très simple.
Cependant, on perd un grand intérêt si, par fichier, il n'y a qu'une seule donnée. En effet, le mécanisme de chunk devient alors inutile. Il reste cependant possible d'utiliser la scalabilité horizontale.
Concernant la partie log, j'avoue ne pas avoir creuser, je ne dirai donc rien sur ce point…
Solution à base d'EIP
Dans le cas où la volonté serait de traiter les fichiers au fil de l'eau, Spring Batch n'est pas la solution la plus adaptée…
Cependant, Spring Integration répond à ce besoin de manière très simple.
En effet, en utilisant un simple Service Activator (au sens EIP) de type inbound-channel-adapter, il devient alors possible de poller un répertoire et d'envoyer le contenu du fichier vers un filter (au sens EIP).
D'un point de vue scalabilité horizontale, il suffit de renseigner (tout comme pour Spring Batch) un taskExecutor au niveau du Channel et… c'est tout!
```xml
<task:executor id=“someExecutor”
pool-size="20"
keep-alive="2400"/>
<int:channel id=“toLogger”>
<int:dispatcher task-executor="someExecutor"/>
</int:channel>
```
Enfin, disposer d'une supervision est des plus aisé puisqu'il suffit de rajouter l'élément message-history :
xml
<int:message-history/>
L'ajout de cet élément indique à Spring Integration qui doit ajouter automatiquement dans le header du message le temps d'exécution de chaque Filter. Concernant le nom du fichier et son chemin, il se trouve renseigner automatiquement dans le header par l'adapterfile:inbound-channel-adapter.
Coté gestion des erreurs, Spring Integration permet de les gérer très simplement sur le principe du canal d'erreur qui peut récupérer tous les messages en erreur.
Cependant, avec Spring Integration, si le fichier est volumineux, il n'est plus possible de le traiter en chunk et un risque de contention mémoire existe.
Solution à base d'EIP et de batch
On a vu dans les deux paragraphe précédent que Spring Integration était une très bonne solution pour traiter des fichiers au fil de l'eau alors que Spring Batch était plutôt orienté traitement par batch.
Cependant, il est très facile de composer les 2 modes. Cela permet, par exemple, de déclencher un traitement d'un fichier volumineux dès sa réception (via Spring Integration) et de bénéficier du mode chunk de Spring Batch pour le traitement.
Dans ce cas, bien sûr, il n'est pas question de faire de traitement sur le contenu du fichier dans la partie Spring Integration (seul l'objet File est transmis dans le corps du message) et c'est le jobs Spring Batch qui s'occupera du traitement à proprement parler.
Cela engendre peut être un overhead conséquent mais on est, au moins sûr, d'éviter le Out Of Memory dans le cas de fichiers volumineux. En outre, cela permet de bénéficier de la puissance des EIP (routage ou filtrage sur le nom du fichier par exemple) tant que le fichier n'a pas à être chargé.
Conclusion
On a vu dans cet article comment il pouvait être trivial de traiter l'import de fichiers sans avoir à gérer manuellement des pools de thread ou des logs d'audit.
Je ne suis pas rentré dans les détails mais mon objectif était surtout de montrer qu'en utilisant les bons outils/framework, il était possible de produire du code minimaliste et donc moins propice aux erreurs.
Pour avoir mis en oeuvre ces solutions, je peux vous assurer que le code écrit (ainsi que le temps passé) était minimaliste sinon nul (si on considère qu'écrire du xml n'est pas du code…). Bien sûr, je ne parle pas du code de traitement qui doit être écrit quoiqu'il arrive mais, encore une fois, le fait d'expédier la partie plomberie a permis de se concentrer sur le réel besoin métier.
Enfin, il est important de préciser que dans certains cas, une telle approche ne fonctionnera pas (si un fichier contient, par exemple, des dépendances à des données issues d'autres fichiers) et qu'il peut même être dangereux de vouloir absoluement utiliser ce type de framework au risque de leur faire faire des choses pour lesquelles ils ne sont pas prévus… Par exemple, il ne faut pas oublier que dans EIP, le I signifie Intégration!! Si le besoin est autre, il est fortement recommandé d'utiliser autre chose ou de le faire manuellement mais, par pitié, ne tordez pas le coup aux outils…! (si si, je l'ai vu… d'où mon désarroi…).
ndlr : bon, j'admets que la partie qui a dû être la plus longue a sûrement été le tuning du pool de thread afin de tirer le meilleur partie de la machine mais, même si cela avait été fait de manière programmatique, cela aurait été nécessaire…
ndlr : j'ai parlé, dans cet article, de Spring Integration pour la partie EIP mais il est tout aussi simple d'utiliser Apache Camel.
Pour aller plus loin…
Spring Integration in Action de Mark Fisher, Jonas Partner, Marius Bogoevici et Iwein Fuld chez Manning
Camel in Action de Claus Ibsen et Jonathan Anstey chez Manning
Spring Batch in Action de Arnaud Cogoluegnes, Thierry Templier, Gary Gregory et Olivier Bazoud chez Manning
Enterprise Integration Patterns de G. Hohpe et B. Woolf chez Addisson Wesley
]]><![CDATA[Logstash : tour d'horizon sur les stratégies de déploiement]]>2014-04-07T11:20:26+02:00https://blog.jetoile.fr/2014/04/logstash-petit-tour-dhorizon
Cet article fera un rapide tour d'horizon sur les différentes stratégies qui peuvent être utilisées pour Logstash.
Pour ce faire, je m'appuierai sur le très bon livre officiel que je me suis procuré (moyennant environ 10€) et qui fournit une très bonne vision sur ce qui est possible de faire ainsi que sur les différents concepts mais également sur les différentes stratégies de déploiement.
Même si je résumerai succinctement quelques-uns des concepts afin que cet article soit un minimum compréhensible, cet article traitera surtout sur la façon dont il est possible de déployer les agents Logstash.
[ndlr : par contre, je ne ferai, comme à mon habitude, que retranscrire ce qui est présent dans le livre…]
Les concepts
Logstash est écrit en JRuby et fonctionne dans une JVM. Son architecture est orientée messages et est très simple. Plutôt que de séparer le concepts d'agents et de serveurs, Logstash se présente comme un simple agent qui est configuré pour combiner différentes fonctions avec d'autres composants open souce.
L'écosystème de Logstash est constitué de 4 composants :
Shipper qui envoie des événements à Logstash.
Broker et Indexer qui reçoivent et indexent les événements.
Search et Stockage qui permettent de rechercher et de stocker les événements.
Web Interface qui est une interface web appelée Kibana.
Les serveurs Logstash sont constitués d'un ou de plusieurs de ces composants indépendamment, ce qui permet de les séparer offrant ainsi la possibilité de scaler mais également de les combiner en fonction du besoin.
Dans le plupart des cas, Logstash sera déployé de la manière suivante :
Les hôtes exécutant les agent Logstash comme des Shipper qui émettent, comme des événements, les logs des applications, services et hôte à un serveur central Logstash. Ces hôtes n'ont besoin de disposer que d'agents Logstash.
Le serveur central Logstash qui aura à sa charge l'exécution du Broker, Indexer, Search, Storage et Web Interface afin de recevoir, processer et stocker les logs.
En fait, une configuration typique de Logstash est la suivante :
```text
input {
stdin { }
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date {
match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
input peut prendre en valeur des plugins qui correspondent à ce que peut prendre en entrée l'agent (comme, par exemple, l'entrée standard ou le contenu d'un fichier).
filter peut prendre en valeur des plugins qui permettent de manipuler l'événement en le parsant, filtrant ou en ajoutant des informations issues du parsing ou non.
output peut prendre en valeur des plugins qui permettent de préciser où seront envoyés les événements (comme, par exemple, la sortie standard ou ElasticSearch).
Les différentes stratégies de déploiement possibles
Le mode de déploiement classique
Dans l'architecture de déploiement classique, on retrouve la stack préconisée qui est la suivante :
Les agents Logstash se trouvant sur les machines hôtes collectent et émettent les logs (sous forme d'événements) au système central.
Une instance d'un système de bufferisation (comme Redis ou autre, comme une implémentation d'AMQP) reçoit les événement sur le serveur central et joue le rôle de buffer.
Un agent Logstash extrait les événements de logs du buffer et les traite.
L'agent Logstash envoie les événements d'index dans ElasticSearch.
ElasticSearch stocke et rend les événements cherchable.
Kibana permet la recherche et le rendu des événements indexés dans ElasticSearch.
En fait, le broker permet de servir de buffer entre les agents et le serveur Logstash. Cela est essentiel pour les raisons suivantes :
Cela permet d'améliorer les performances de l'environnement Logstash en fournissant une buffer de cache pour les événements de log.
Cele permet de fournir de la résiliance. Si l'indexation Logstash échoue, alors les événements sont mise en fils d'attente afin d'éviter la perte d'informations.
On observe donc, dans cette configuration, que les agents Logstash présents sur les machines hôtes ne font que transmettre sans intelligence réelle au buffer les différents événements de log et qu'ils n'ont pas vraiment de logique (ie. ils n'ont pas de section filter mais juste les sections input et output).
Le mode de déploiement sans agent
A la mode système
Comme on a pu voir dans le paragraphe précédent, les machines hôtes disposent d'un agent Logstash complet. Cependant, ils n'ont pas vraiment de logique puisqu'ils ne font que transmettre les événements de logs au broker dont le rôle est de servir de buffer.
Cependant, parfois, il peut être intéressant de ne pas à avoir besoin d'installer un agent Logstash sur les machines hôtes :
si la JVM déployé sur la machine hôte est limitée,
si la machine hôte est un périphérique qui dispose de peu de ressource et qu'il n'est pas possible d'y installer une JVM ou d'exécuter un agent,
s'il n'est pas possible d'installer n'importe quel logiciel sur la machine hôte.
Pour répondre à cette problématique, il est possible d'utiliser des outils systèmes comme Syslog.
Dans ce cas, le serveur Logstash n'aura qu'à déclarer un input supplémentaire permettant d'écouter des événéments (dans notre cas, Syslog).
A titre informatif, il est possible d'utiliser un Appender syslog dans log4j ou logback (entre autre).
A la mode agent
Dans le cas où ni un agent Logstash ni Syslog ne sont envisageables, il est possible d'utiliser Logstash Forwarder (anciennement Lumberjack).
Il s'agit d'un client légé permettant d'envoyer des messages à Logstash en offrant un protocole maison intégrant de la sécurité (encryption SSL) ainsi que de la compression.
Il a été conçu pour être petit avec une faible emprunte mémoire tout en étant rapide. Il a été écrit en Go.
Dans ce cas, il suffit d'exécuter logstash-forwarder avec les bons fichiers de configuration spécifiant l'adresse du serveur cible ainsi que l'emplacement du certificat et les fichiers à scruter.
Du coté serveur, il suffit, tout comme pour le mode sans agent à base de Syslog, de déclarer un input lumberjack.
A noter que d'autres shipper sont également disponibles tels que :
Logstash vient avec un système de filtre qu'il est possible de configurer via la section filter.
Ces filtres permettent de filtrer mais également de modifier (via mutable) le contenu de l'événement. Ils permettent également de parser les événements (via grok) afin de les rajouter lors de la phase d'indexation (et donc de stockage). Cela permet ainsi de pouvoir rechercher des événements de manière plus ciblé.
Il existe plusieurs stratégies lors de l'utilisation de filtres :
filtrer les événements sur l'agent,
filtrer les événements sur le serveur central,
émettre les événements au bon format.
Le plus simple est encore d'émettre les logs au bon format, cependant, cela n'est pas toujours possible (trop de log différents, systèmes hétérogènes, code legacy, …).
Une autre manière de faire est d'exécuter le filtrage localement (ie. directement sur l'agent). Cela permet de réduire la charge de traitement du serveur central et d'être sûr que seuls les événements propres et structurés seront stockés. Cependant, cela oblige à maintenir une configuration plus complexe sur chaque agent.
A l'inverse, si le filtrage est effectué sur le serveur central, cela permet de centraliser les filtres et permet donc une administration plus simple. Cependant, cela demande des ressources supplémentaires pour effectuer le filtrage sur un plus grand nombre d'événements.
La scalabilité et Logstash
Une des grande force de Logstash est qu'il est possible de le composer avec différents composants : Logstash lui-même, Redis comme broker, ElasticSearch et bien d'autres éléments qu'il est possible de composer via la configuration de Logstash.
Ainsi, il est possible de jouer à plusieurs niveaux pour répondre à telles ou telles problématiques comme la perte de messages, le fait d'avoir un SPOF (Single Point Of Failure) ou d'avoir un point de contention dans le système.
Par exemple, si Redis est utilisé comme broker entre les agents Logstash et le serveur central, il peut être intéressant de passer Redis en mode failover afin d'éviter une perte d'événements lors de la transmission de ces derniers. Pour ce faire, il suffit de configurer le plugin redis de la section output avec l'option shuffle_hosts pour indiquer à l'agent Logstash de n'utiliser qu'un seul noeud Redis lors de sa phase d'écriture. Du coté du serveur central, il suffit d'ajouter (et de configurer) autant de plugin redis de la section input que de noeud.
Afin de permettre à la partie stockage/indexation d'être scalable, il suffit de configurer ElasticSearch en mode cluster, ce qui est natif chez lui.
Enfin, il est possible de rendre le serveur central Logstash robuste à la panne en en créant d'autres instances (mode failover) qui partageront la même configuration.
Conclusion
En conclusion de cet article où je ne suis pas rentré dans les détails (mais ce n'est pas ce qui m'intéressait…), on peut constater qu'il existe moultes façons de configurer Logstash (et son écosystème) qui dépendent à chaque fois des besoins.
Cela est rendu possible par l'architecture et la conception modulaire de Logstash et le fait qu'il est très simple de le plugger à différentes solutions.
Même si cela est évident, je trouvais utile de le marquer noir sur blanc dans un court article… ;–)
Il y a déjà un long moment, j'avais posté une série d'article expliquant comment il était possible de faire des web service de type REST de manière simple via RestEasy-Netty ou via Undertow.
Il y a quelques temps, j'avais fait une série d'articles sur resteasy-netty et resteasy-netty4.
Pour ceux qui auraient manqué l'information, le BreizhCamp s'est déroulé en mai dernier et j'y avais la chance d'y présenter un talk sur un retour d'expérience concernant le passage à l'échelle d'un SI afin de lui permettre de supporter 4 millions d'utilisateurs.
Cet article fera un rapide tour d'horizon sur les différentes stratégies qui peuvent être utilisées pour Logstash.
