wor-prof 0.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +331 -0
- data/.rubocop.yml +57 -0
- data/.travis.yml +35 -0
- data/Gemfile +20 -0
- data/LICENSE +21 -0
- data/README.md +86 -0
- data/Rakefile +6 -0
- data/bin/console +14 -0
- data/bin/setup +8 -0
- data/doc/user-guide_en.md +308 -0
- data/doc/user-guide_es.md +297 -0
- data/lib/generators/wprof_generator.rb +42 -0
- data/lib/generators/wprof_model_generator.rb +14 -0
- data/lib/wor-prof.rb +18 -0
- data/lib/wprof/conf_wprof.rb +25 -0
- data/lib/wprof/gen_prof.rb +73 -0
- data/lib/wprof/reporters/db_report.rb +16 -0
- data/lib/wprof/reporters/external_report.rb +13 -0
- data/lib/wprof/reporters/file_report.rb +59 -0
- data/lib/wprof/supports/style_support.rb +9 -0
- data/lib/wprof/version.rb +3 -0
- data/lib/wprof/wprof_modules.rb +32 -0
- data/lib/wprof/wprof_reporter.rb +34 -0
- data/lib/wprof/wprof_subscriptors.rb +16 -0
- data/wor-prof.gemspec +36 -0
- metadata +271 -0
@@ -0,0 +1,308 @@
|
|
1
|
+
# Wor-Prof
|
2
|
+
|
3
|
+
Wor-prof (Wprof) is a gem for Ruby On Rails which its only purpose is to measure a RoR app's performance through a profile with different times of response. In order to accomplish that, Wprof uses ActiveSupport::Notifications (available in Rails since v4.0.2) to capture every action from his controllers. However, there's more. when using httparty in your project, you can capture every done request to external services. Do you have one or two methods that would like to know how long they take to execute? With Wprof you can find out.
|
4
|
+
|
5
|
+
Then, every data obtained can be reported in several ways, choose one from the Rails logger: database file, CSV text or go ahead and do a Post request wherever you want... Do it both synchronously or asynchronously.
|
6
|
+
|
7
|
+
---
|
8
|
+
|
9
|
+
## Let's begin.
|
10
|
+
|
11
|
+
The first step is the gem install (of course) and the way to do it is well known. However, just in case, you'll find the steps to follow next.
|
12
|
+
|
13
|
+
### Installation
|
14
|
+
|
15
|
+
Add the next line to the gemfile from your Rails application:
|
16
|
+
|
17
|
+
```ruby
|
18
|
+
gem 'wor-prof'
|
19
|
+
```
|
20
|
+
|
21
|
+
And then, execute:
|
22
|
+
```bash
|
23
|
+
$ bundle install
|
24
|
+
```
|
25
|
+
**That's it!!** At server execution, WProf immediately begins to work with default settings, so you won't need to configure anything if it matches with your needs, otherwise you can check **Available Settings**.
|
26
|
+
|
27
|
+
---
|
28
|
+
|
29
|
+
## Register Types and how they works.
|
30
|
+
|
31
|
+
As register types, Wprof counts with the following.
|
32
|
+
|
33
|
+
* Controllers: every request realized to Rails' App that is handled by a Controller. (this is a default setting and cannot be disabled)
|
34
|
+
* HTTParty: every time an HTTParty method is involved.
|
35
|
+
* Own methods: an array of methods can be defined to be captured.
|
36
|
+
``Only "controllers" are automatically profiled by just adding the gem, every other one will need an extra configuration or operation.``
|
37
|
+
|
38
|
+
### HTTparty
|
39
|
+
|
40
|
+
HTTParty is a popular tool for Ruby that allows to easily make HTTP's requests.
|
41
|
+
If you're not used to the gem I recommend you to read more information in its repository, right [here!](https://github.com/jnunemaker/httparty)
|
42
|
+
|
43
|
+
In order to profile the requests made by HTTParty, you must include Wprof right after Httparty. This is:
|
44
|
+
|
45
|
+
```ruby
|
46
|
+
class FooClass
|
47
|
+
include HTTParty
|
48
|
+
include Wprof
|
49
|
+
```
|
50
|
+
What that does mean? Wprof make a wrapper over every called method as class methods, waits for the response and captures some of the needed data to generate the profile. This is why you **must include the module right after HTTParty**... Otherwise, it would simply not work.
|
51
|
+
|
52
|
+
By default, WProf defines the methods that are commonly used to generate a request (Get, Put, Delete, Post), however you can define or exclude some of that list. It's **strongly recommended not to add** HTTParty's methods without being completely certain that the result is what WProf will try to capture (See 'captured Data' to know which are they)
|
53
|
+
|
54
|
+
### Own methods
|
55
|
+
|
56
|
+
Sometimes it may result useful to know how much an specific method is taking to execute, to this end Wor-prof can help you out.
|
57
|
+
|
58
|
+
There are two steps to accomplish that.
|
59
|
+
|
60
|
+
1. Prepare an array of methods which you want to trace (check configuration section: "custom_methods")
|
61
|
+
2. Include WProf to that method's class
|
62
|
+
|
63
|
+
Done, with this WProf will be registering the execution time of said method every time is being called and then it will report it.
|
64
|
+
|
65
|
+
---
|
66
|
+
|
67
|
+
## Available Configurations.
|
68
|
+
|
69
|
+
WProf contains a list of default settings which can all be altered by others availables as user's preferences demands. In order to do that, create a file in 'config/initializers' (RailsApp.Root >> config >> initializers >> wprof.rb). Inside, you must define the following configuration:
|
70
|
+
|
71
|
+
```ruby
|
72
|
+
Rails.application.configure do
|
73
|
+
config.x.wprof.db_runtime = true
|
74
|
+
config.x.wprof.reporter_type = 'FILE'
|
75
|
+
end
|
76
|
+
```
|
77
|
+
> In case of not correctly configuring an option or just skip it, the value would be default.
|
78
|
+
|
79
|
+
To avoid this configuration manually using the **configuration generator** with the command "rails generate wprof" (see generator section).
|
80
|
+
|
81
|
+
Following the complete list of available settings and their meaning.
|
82
|
+
|
83
|
+
### config.x.wprof.db_runtime
|
84
|
+
Sets whether it shows or not the data "db_runtime" inside the report.
|
85
|
+
|
86
|
+
> Possible values: true o false
|
87
|
+
|
88
|
+
> Default: true
|
89
|
+
|
90
|
+
### config.x.wprof.reporter_type
|
91
|
+
Sets report type, meaning, how to show the obtained data. There are currently 4 available types, see "Reports" section for more information.
|
92
|
+
|
93
|
+
> Possible values: LOGGER, FILE, DATABASE, EXTERNAL
|
94
|
+
|
95
|
+
> Default: LOGGER
|
96
|
+
|
97
|
+
### config.x.wprof.csv_type
|
98
|
+
When the report is defined as a CSV file there are two ways of generate it.
|
99
|
+
* **MIX:** generates one CSV file where every data captured by WProf is saved. This file only contains 2 columns: in the first one is the field and in the second one the data.
|
100
|
+
* **SPLIT:** Divides storage in three different files, one for each record type. This significantly improves reading since every field is held as the file's header and the data in rows is split by comma... As it should be, of course... Why mix then?, I don't know, it could be useful for someone!
|
101
|
+
> Possible values: MIX, SPLIT.
|
102
|
+
> Default: SPLIT
|
103
|
+
|
104
|
+
### config.x.wprof.async
|
105
|
+
Sets whether the report is being generated sinchronously or not. **Take note: asynchronous mode requires extra steps, see "asynchronism" section for more information.**
|
106
|
+
> Possible values: false, true
|
107
|
+
> Default: false
|
108
|
+
|
109
|
+
### config.x.wprof.httparty_methods_to_trace
|
110
|
+
HTTParty's method captured by WProf. By default, more common ones are set and it's recommended not to modify.
|
111
|
+
This being said, there's no problem in taking out some of the array, however take special care in adding HTTParty's methods which doesn't return an http request.
|
112
|
+
> Possible values: what you want and need, must be an **array of strings**.
|
113
|
+
> Default: ['get', 'put', 'delete', 'post']
|
114
|
+
|
115
|
+
### config.x.wprof.external_url
|
116
|
+
In case you configure reporter_type as External, you must indicate the URL which will receive the HTTP petition.
|
117
|
+
> Possible values: any string that corresponds to an URL. Example: 'http://example-url/reporter'
|
118
|
+
> Default: nil
|
119
|
+
|
120
|
+
### config.x.wprof.external_headers
|
121
|
+
To add a header to the http request ("external" report type), you must define it in this setting. This must be a **HASH of RUBY**, exactly as HTTParty expects (internally Wprof uses HTTParty to send a request). An example would be:
|
122
|
+
|
123
|
+
``` ruby
|
124
|
+
config.x.wprof.external_headers = { headers: {'User-Agent' => 'Httparty'}}
|
125
|
+
```
|
126
|
+
> Possible : Any valid hash, must respect primary key as "headers" (check example below)
|
127
|
+
> Default: nil
|
128
|
+
|
129
|
+
### config.x.wprof.custom_methods
|
130
|
+
If you want to capture response times of an specific method inside a class, it's not enough including the module, you'll need to indicate WProf exactly which is the one it has to capture.
|
131
|
+
This list of methods must be contained in this option in a **array of Ruby** and it has to be strings.
|
132
|
+
Example:
|
133
|
+
``` ruby
|
134
|
+
config.x.wprof.custom_methods = [ 'my_great_method' ]
|
135
|
+
```
|
136
|
+
> Possible values: any method's name in string format, within an array. Default: nil
|
137
|
+
|
138
|
+
### config.x.wprof.file_path
|
139
|
+
|
140
|
+
When "FILE" is used as an output, this option allows you to choose the files destination. This must be a valid route, as string, with reading permission for Rails and also be a folder.
|
141
|
+
Example:
|
142
|
+
``` ruby
|
143
|
+
config.x.wprof.file_path = '/home/mcolombo/examplefolder'
|
144
|
+
```
|
145
|
+
> Possible values: any string that correctly represents a PATH to a directory.
|
146
|
+
> Default: Rails.root is used, so, root is Rails application.
|
147
|
+
|
148
|
+
---
|
149
|
+
|
150
|
+
## Generators.
|
151
|
+
|
152
|
+
WProf has two Rails generators availables.
|
153
|
+
|
154
|
+
---
|
155
|
+
|
156
|
+
### Configuration file Generator.
|
157
|
+
|
158
|
+
To begin to modify options from available settings, you must create a config file inside the 'config/initializers' (as mentioned in "available configurations" section). To avoid unnecessary steps and possible mistakes in the well known dangerous 'copy/paste', you can generate this file as a template with the following Rails command:
|
159
|
+
|
160
|
+
```
|
161
|
+
rails generate wprof
|
162
|
+
```
|
163
|
+
This generates a model of the configuration's file with all the available options seen in "available configurations" section.
|
164
|
+
|
165
|
+
### Data Model Generator
|
166
|
+
|
167
|
+
An available option to report captured information is the same database Rails uses, the problem is, this requires defining the model. This generator will create all of the migration files and the models for using this option without having to worry for anything else.
|
168
|
+
```
|
169
|
+
rails generate wprof_model
|
170
|
+
```
|
171
|
+
This will generate the migration files and the models (even controllers in case you want to handle them!)
|
172
|
+
**Remember: in order to models be available in the case you still must run the migration.**
|
173
|
+
```
|
174
|
+
rails db:migrate
|
175
|
+
```
|
176
|
+
|
177
|
+
---
|
178
|
+
|
179
|
+
## Captured Data.
|
180
|
+
|
181
|
+
Data captured and reported by WProf vary depending on which record they come, although, all of them share some base data.
|
182
|
+
|
183
|
+
### Base data (common to all)
|
184
|
+
|
185
|
+
* **transaction_id:** unique identifier for each transaction. This field is vital due to HTTParty's records and methods share this same identifier with the request that triggered this execution, allowing a complete execution trace of each one of them.
|
186
|
+
* **total_time:** Total execution time registered (in milliseconds).
|
187
|
+
* **start_dt:** Date and time field when register began.
|
188
|
+
* **end_dt:** Date and time field when register ended.
|
189
|
+
|
190
|
+
### Unique for the controller.
|
191
|
+
|
192
|
+
* **code:** Response code sensed by the controller (Status), eg. 200, 404, etc.
|
193
|
+
* **controller:** Controller that handled the request.
|
194
|
+
* **url:** Endpoint that received the petition.
|
195
|
+
* **db_runtime:** total time when it was absorbed by the database (included in total_time).
|
196
|
+
|
197
|
+
### Únicos para los Servicios (Httparty).
|
198
|
+
|
199
|
+
* **code:** Código de respuesta recibido (Status), ej. 200, 404, etc.
|
200
|
+
* **service_hostname:** Hostname del servicio consumido.
|
201
|
+
* **request_uri:** Uri del endpoint consumido.
|
202
|
+
|
203
|
+
### Unique for services (Httparty).
|
204
|
+
|
205
|
+
* **method:** measured method's name.
|
206
|
+
|
207
|
+
---
|
208
|
+
|
209
|
+
## Reports.
|
210
|
+
|
211
|
+
Destination of the data, once is captured and processed, varies in order of user’s preferences Wor-Prof offers the following destinations for the information:
|
212
|
+
* **LOGGER:** Uses Rails.logger to show the information.
|
213
|
+
* **FILE:** Saves the info in one or several text files, split by comma (csv)
|
214
|
+
* **DATABASE:** Saves obtained data in the same database used by Rails (requires model preparation, see generator/s of data model)
|
215
|
+
* **EXTERNAL:** Does a POST petition with the data sended in the body in a JSON format (requires additional configuration)
|
216
|
+
|
217
|
+
> "Logger" as well as "File" don’t need additional configuration to work, however “Database” and “External” require some previous step.
|
218
|
+
|
219
|
+
### Database Reporter
|
220
|
+
|
221
|
+
For **DATABASE** is necessary to generate a schema that allows information storage. To accomplish this, we provide a generator, however, if you want to manually generate WProf you need the following models (Migration files are exposed).
|
222
|
+
|
223
|
+
> Modelo: WprofController
|
224
|
+
``` ruby
|
225
|
+
class CreateWprofControllers < ActiveRecord::Migration[5.0]
|
226
|
+
def change
|
227
|
+
create_table :wprof_controllers do |t|
|
228
|
+
t.string :transaction_id
|
229
|
+
t.float :total_time
|
230
|
+
t.datetime :start_dt
|
231
|
+
t.datetime :end_dt
|
232
|
+
t.integer :code
|
233
|
+
t.string :controller
|
234
|
+
t.string :url
|
235
|
+
t.float :db_runtime
|
236
|
+
|
237
|
+
t.timestamps
|
238
|
+
end
|
239
|
+
add_index :wprof_controllers, :transaction_id
|
240
|
+
add_index :wprof_controllers, :code
|
241
|
+
add_index :wprof_controllers, :url
|
242
|
+
end
|
243
|
+
end
|
244
|
+
```
|
245
|
+
> Modelo: WprofService
|
246
|
+
``` ruby
|
247
|
+
class CreateWprofServices < ActiveRecord::Migration[5.0]
|
248
|
+
def change
|
249
|
+
create_table :wprof_services do |t|
|
250
|
+
t.string :transaction_id
|
251
|
+
t.float :total_time
|
252
|
+
t.datetime :start_dt
|
253
|
+
t.datetime :end_dt
|
254
|
+
t.integer :code
|
255
|
+
t.string :service_hostname
|
256
|
+
t.string :request_uri
|
257
|
+
|
258
|
+
t.timestamps
|
259
|
+
end
|
260
|
+
add_index :wprof_services, :transaction_id
|
261
|
+
add_index :wprof_services, :code
|
262
|
+
add_index :wprof_services, :service_hostname
|
263
|
+
add_index :wprof_services, :request_uri
|
264
|
+
end
|
265
|
+
end
|
266
|
+
```
|
267
|
+
> Modelo: WprofMethod
|
268
|
+
``` ruby
|
269
|
+
class CreateWprofMethods < ActiveRecord::Migration[5.0]
|
270
|
+
def change
|
271
|
+
create_table :wprof_methods do |t|
|
272
|
+
t.string :transaction_id
|
273
|
+
t.float :total_time
|
274
|
+
t.datetime :start_dt
|
275
|
+
t.datetime :end_dt
|
276
|
+
t.string :method
|
277
|
+
|
278
|
+
t.timestamps
|
279
|
+
end
|
280
|
+
add_index :wprof_methods, :transaction_id
|
281
|
+
add_index :wprof_methods, :method
|
282
|
+
end
|
283
|
+
end
|
284
|
+
```
|
285
|
+
|
286
|
+
### External Request Reporter.
|
287
|
+
An option is sending data by HTTP wherever you want. Data obtained by Wprof will be sended in the body as JSON format. In order for this to work well it’s **necessary to configure destination’s URL**. Petition generated is POST and, when needed, you can configure the necessary HEADERS. If the URL is not configured, petition won’t be sended.
|
288
|
+
The options to be set are: external_url and external_headers. See Configurations section for more information.
|
289
|
+
|
290
|
+
---
|
291
|
+
|
292
|
+
## Asynchronism.
|
293
|
+
|
294
|
+
WProf by default reports all the information **synchronous**, although it’s possible to configure the tool in order to do this process **asynchronous**. To achieve this, you must first activate the option through config field "config.x.wprof.async = true", however this is not enough. For all of the report be made asynchronous, you must have functional and operational **Sidekiq**, since WProf uses it to that purpose. If you’re not familiar with the tool, you could give it a look to its [repository by clicking here!.](https://github.com/mperham/sidekiq).
|
295
|
+
|
296
|
+
---
|
297
|
+
|
298
|
+
## Handled errors.
|
299
|
+
|
300
|
+
Any error among the capture and report of the information **MUSTN’T** interrupt the normal functioning of your Rails application. If this is the case, please report it. During the execution, could show up two errors in application’s logger.
|
301
|
+
WProf ERROR when try parsing service response:
|
302
|
+
An error was raised when WProf tried to send data to reporter: This is the most common error and it will appear if the data sending to the selected destination (meaning Logger, Database, File o External) has failed.
|
303
|
+
|
304
|
+
```WProf ERROR when try parsing service response:``` This error may appear if HTTParty wouldn’t be able to capture some data.
|
305
|
+
|
306
|
+
```An error was raised when WProf tried to send data to reporter:``` This is the most common error and it will appear if the data sending to the selected destination (meaning Logger, Database, File o External) has failed.
|
307
|
+
|
308
|
+
---
|
@@ -0,0 +1,297 @@
|
|
1
|
+
# Wor-Prof
|
2
|
+
|
3
|
+
Wor-prof (Wprof) es una gema para Ruby On Rails cuyo único objetivo es el medir el rendimiento de una aplicación RoR mediante un perfil de distintos tiempos de respuesta. Para lograrlo, Wprof utiliza ActiveSupport::Notifications (disponible en Rails desde la versión 4.0.2) para capturar toda acción de sus controladores. Pero no sólo eso, si usas httparty en tu proyecto también puedes capturar cada request realizada a servicios externos. Tienes uno o más métodos que también quisieras conocer cuánto se demoran en ejecutarse? Con Wprof puedes saberlo. Luego, cada dato obtenido puede reportarse de distintas formas, elige una entre el logger de Rails, base de datos, archivo de texto en formato CSV o bien realiza un request Post a donde quieras… hazlo de forma sincrónica o asíncrona.
|
4
|
+
|
5
|
+
---
|
6
|
+
|
7
|
+
## Comenzar.
|
8
|
+
|
9
|
+
El primer paso es instalar la gema (por supuesto) y la forma es bien conocida, pero por si acaso acá están los pasos a seguir.
|
10
|
+
|
11
|
+
### Installation
|
12
|
+
Agregar la siguiente línea en el gemfile de tu aplicación Rails:
|
13
|
+
|
14
|
+
```ruby
|
15
|
+
gem 'wor-prof'
|
16
|
+
```
|
17
|
+
|
18
|
+
Y luego ejecute:
|
19
|
+
```bash
|
20
|
+
$ bundle install
|
21
|
+
```
|
22
|
+
**Eso es todo!!** Al correr el servidor Wprof comienza inmediatamente a trabajar con la configuración por defecto por lo que no hay que configurar nada si coincide con sus necesidades, pero si no es así puede consultar la sección de **Configuraciones Disponibles**.
|
23
|
+
|
24
|
+
---
|
25
|
+
|
26
|
+
## Tipos de registros y cómo funciona.
|
27
|
+
|
28
|
+
Como tipo de registros WProf cuenta con los siguientes.
|
29
|
+
|
30
|
+
* Controladores: Cada request realizada a Rails que es manejada por un *Controller*. (Esto viene por defecto y no puede desactivarse)
|
31
|
+
* HTTParty: Cada vez que se invoca un método de HTTParty.
|
32
|
+
* Métodos propios: Se puede definir un Array de Métodos a capturar.
|
33
|
+
|
34
|
+
``Solamente "Controladores" son automáticamente perfilados con sólo agregar la gema, el resto necesita alguna configuración u operación extra.``
|
35
|
+
|
36
|
+
### HTTparty
|
37
|
+
HTTParty es una popular herramienta para Ruby que permite realizar fácilmente peticiones HTTP. Si no está familiarizado con la gema le recomiendo leer más sobre está en el repositorio de la misma, [aquí!](https://github.com/jnunemaker/httparty)
|
38
|
+
|
39
|
+
Para poder perfilar las request que se hacen mediante HTTParty debe incluir Wprof justo después de Httparty. Es decir:
|
40
|
+
```ruby
|
41
|
+
class FooClass
|
42
|
+
include HTTParty
|
43
|
+
include Wprof
|
44
|
+
```
|
45
|
+
Qué significa esto? Wprof envuelve los métodos invocados como métodos de clase, espera la respuesta y captura algunos datos necesarios para generar el perfil. Es por esto que la inclusión del módulo debe ser **obligatoriamente** después de HTTParty... si esto no es así, sencillamente no funcionará.
|
46
|
+
|
47
|
+
Por defecto, WProf define los métodos que comúnmente se utilizan para generar una petición (Get, Put, Delete, Post), sin embargo puede definir otros o bien quitar alguno de esos de la lista. Es **fuertemente recomendado** no **agregar** métodos de HTTParty sin estar completamente seguro que el retorno de estos coincide con lo que WProf buscará capturar (puede consultar la sección "Datos Capturados" para conocer cuales son).
|
48
|
+
|
49
|
+
### Métodos propios
|
50
|
+
|
51
|
+
Algunas veces puede resultar de utilidad conocer cuánto se demora un método específico en ejecutarse, para este fin Wor-prof puede extender una mano.
|
52
|
+
|
53
|
+
Para lograrlo se necesitan seguir 2 pasos.
|
54
|
+
|
55
|
+
1. Preparar un array de métodos que se desean trazar (consulte la sección de configuración: "custom_methods")
|
56
|
+
2. Incluir Wprof a la clase que tiene dicho método.
|
57
|
+
|
58
|
+
Listo, con esto Wprof estará registrando el tiempo de ejecución de dicho método cada vez que sea invocado y lo reportará.
|
59
|
+
|
60
|
+
---
|
61
|
+
|
62
|
+
## Configuraciones disponibles.
|
63
|
+
|
64
|
+
Por defecto Wprof continúe una lista de configuraciones por defecto, pero todas estas pueden ser modificadas por otras disponibles de acuerdo a las preferencias del usuario. Para lograr esto se debe crear un archivo en 'config/initializers' (RailsApp.Root >> config >> initializers >> wprof.rb).
|
65
|
+
Dentro del mismo se debe definir la configuración de esta manera:
|
66
|
+
|
67
|
+
```ruby
|
68
|
+
Rails.application.configure do
|
69
|
+
config.x.wprof.db_runtime = true
|
70
|
+
config.x.wprof.reporter_type = 'FILE'
|
71
|
+
end
|
72
|
+
```
|
73
|
+
> En caso de no configurar correctamente una opción u omitirla, se tomarán los valores por defecto.
|
74
|
+
|
75
|
+
Para evitar esta configuración manualmente utilizando el **Generador de Configuración** con el comando "rails generate wprof" (consulte la sección de generadores).
|
76
|
+
|
77
|
+
A continuación se ofrece la lista completa de configuraciones disponibles y sus significados.
|
78
|
+
|
79
|
+
### config.x.wprof.db_runtime
|
80
|
+
Define si se debe mostrar o no el dato "db_runtime" dentro del reporte.
|
81
|
+
> Valores Posibles: true o false
|
82
|
+
> Por defecto: true
|
83
|
+
|
84
|
+
### config.x.wprof.reporter_type
|
85
|
+
Establece el tipo de reporte, es decir, como exponen los datos obtenidos, existen cuatro tipo disponible actualmente, Ver sección "Reportes" para más información.
|
86
|
+
> Valores Posibles: LOGGER, FILE, DATABASE, EXTERNAL
|
87
|
+
> Por defecto: LOGGER
|
88
|
+
|
89
|
+
### config.x.wprof.csv_type
|
90
|
+
Cuando se define el reporte como un archivo CSV existen dos formas de generarlos.
|
91
|
+
* **MIX:** Genera un único archivo CSV donde se guardan los datos de **todo** lo que captura WProf. Este archivo solo tiene 2 columnas: En la primera se guarda el campo y en la segunda el dato.
|
92
|
+
* **SPLIT:** Divide el almacenamiento en tres archivos distintos, uno por cada tipo de registro. Esto mejora significamente la lectura ya que cada campo está como encabezado del archivo y los datos en la filas separados por coma... como debe ser claro... ¿Por que mix entonces?, no sé, a alguno le puede servir!
|
93
|
+
> Valores Posibles: MIX, SPLIT
|
94
|
+
> Por defecto: SPLIT
|
95
|
+
|
96
|
+
### config.x.wprof.async
|
97
|
+
Define si el reporte se gestará de forma Sincrónica o Asincronica. **Tome nota: la forma asincrónica requiere pasos adicionales, consulte la sección de "Asincronismo" para más información**
|
98
|
+
> Valores Posibles: false, true
|
99
|
+
> Por defecto: false
|
100
|
+
|
101
|
+
### config.x.wprof.httparty_methods_to_trace
|
102
|
+
Métodos de HTTParty que WProf va a capturar. Por defecto se colocan los más comunes y se recomienda no modificar. Dicho esto, no hay problema en quitar algunos del array, pero tenga especial cuidado en agregar métodos de HTTParty que no devuelvan un request HTTP).
|
103
|
+
> Valores Posibles: Los que quiera, debe si o si ser un **Array** de strings.
|
104
|
+
> Por defecto: ['get', 'put', 'delete', 'post']
|
105
|
+
|
106
|
+
### config.x.wprof.external_url
|
107
|
+
En caso de que se configure el reporter_type como External, se debe indicar la URL a la que se enviará la petición HTTP.
|
108
|
+
> Valores posibles: Cualquier cadena de texto que corresponda a una URL. Ejemplo: 'http://example-url/reporter'
|
109
|
+
> Por defecto: nil
|
110
|
+
|
111
|
+
### config.x.wprof.external_headers
|
112
|
+
Para agregar una cabecera al request HTTP (para el tipo de reporte "External"), debe definirlo en esta configuración. La misma debe ser un **HASH de RUBY** tal cual como espera HTTParty recibir (internamente Wprof utiliza HTTParty para enviar el request). Un ejemplo de esto sería:
|
113
|
+
``` ruby
|
114
|
+
config.x.wprof.external_headers = { headers: {'User-Agent' => 'Httparty'}}
|
115
|
+
```
|
116
|
+
> Valores posibles: Cualquier hash válido, debe respetarse la primera clave como "headers" (ver ejemplo arriba)
|
117
|
+
> Por defecto: nil
|
118
|
+
|
119
|
+
### config.x.wprof.custom_methods
|
120
|
+
Si desea capturar los tiempos de respuesta de un método específico dentro de una clase, no basta con incluir el módulo, debe indicarle a Wprof cual es exactamente aquel que desea capturar. Esta lista de métodos debe estar contenida en está opción dentro de un **Array de Ruby** y deben ser strings. Ejemplo:
|
121
|
+
``` ruby
|
122
|
+
config.x.wprof.custom_methods = [ 'my_great_method' ]
|
123
|
+
```
|
124
|
+
> Valores posibles: Cualquier nombre de método en formato string, contenido en un array.
|
125
|
+
> Por defecto: nil
|
126
|
+
|
127
|
+
### config.x.wprof.file_path
|
128
|
+
|
129
|
+
Cuando se utiliza "FILE" como salida de datos, esta opción permite elegir la ruta de destino de los archivos. Esta debe ser una ruta válida, en formato string, con permisos de escritura para la aplicación Rails y cuyo último valor debe ser una carpeta. Ejemplo:
|
130
|
+
``` ruby
|
131
|
+
config.x.wprof.file_path = '/home/mcolombo/examplefolder'
|
132
|
+
```
|
133
|
+
> Valores posible: Cualquier string que represente correctamente un PATH hasta un directorio.
|
134
|
+
> Por defecto: Se utiliza 'Rails.root', es decir, la raíz de su aplicación Rails.
|
135
|
+
|
136
|
+
---
|
137
|
+
|
138
|
+
## Generadores.
|
139
|
+
|
140
|
+
WProf tiene disponible dos [generadores de Rails](https://guides.rubyonrails.org/command_line.html#rails-generate) disponibles.
|
141
|
+
|
142
|
+
---
|
143
|
+
|
144
|
+
### Generador del archivo de Configuración.
|
145
|
+
|
146
|
+
Para comenzar a modificar las opciones de configuración disponibles, debe crear un archivo de configuración dentro de los 'config/initializers' (como se mencionó en la sección "Configuraciones disponibles"). A favor de evitar pasos innecesarios y posibles equivocaciones en los peligrosos 'copy/paste', puede generar este archivo como un template con el siguiente comando Rails:
|
147
|
+
|
148
|
+
```
|
149
|
+
rails generate wprof
|
150
|
+
```
|
151
|
+
Esto generará un modelo del archivo de configuración, con todas las opciones disponibles vistas en la sección "Configuraciones disponibles".
|
152
|
+
|
153
|
+
### Generador del modelo de datos
|
154
|
+
|
155
|
+
Una opción disponible para reportar la información capturada es la misma Base de Datos que utiliza Rails, pero el problema de esto es que se requiere justamente definir el modelo. Este generador creará todos los archivos de migración y los modelos para poder utilizar esta opción sin preocuparse por nada más.
|
156
|
+
```
|
157
|
+
rails generate wprof_model
|
158
|
+
```
|
159
|
+
Esto generará los archivos de migración y los modelos (incluso los controladores por si desea manejarlos!)
|
160
|
+
**Recuerde que para que los modelos se encuentren disponibles en la base aún debe correr la migración**
|
161
|
+
```
|
162
|
+
rails db:migrate
|
163
|
+
```
|
164
|
+
|
165
|
+
---
|
166
|
+
|
167
|
+
## Datos capturados.
|
168
|
+
|
169
|
+
Los datos que captura y reporta WProf varían de acuerdo a que tipo de registro proviene, sin embargo, todos comparten algunos datos base.
|
170
|
+
|
171
|
+
### Datos base (comunes para todos)
|
172
|
+
|
173
|
+
* **transaction_id:** identificador único de cada transacción. Este campo es de vital importancia debido a que los registros de HTTParty y Métodos comparten este mismo identificador con el Request que disparó esta ejecución permitiendo una traza completa de la ejecución de cada uno.
|
174
|
+
* **total_time:** Tiempo total de ejecución registrado (en milisegundos).
|
175
|
+
* **start_dt:** Campo de Fecha y Hora en que comenzó a registrarse.
|
176
|
+
* **end_dt:** Campo de Fecha y Hora en que finalizó el registro.
|
177
|
+
|
178
|
+
### Únicos para el Controlador.
|
179
|
+
|
180
|
+
* **code:** Código de respuesta enviado por el controlador (Status), ej. 200, 404, etc.
|
181
|
+
* **controller:** Controlador que manejó el request.
|
182
|
+
* **url:** endpoint que recibió la solicitud.
|
183
|
+
* **db_runtime:** Tiempo total que fue absorbido por la Base de Datos (incluido en el total_time).
|
184
|
+
|
185
|
+
### Únicos para los Servicios (Httparty).
|
186
|
+
|
187
|
+
* **code:** Código de respuesta recibido (Status), ej. 200, 404, etc.
|
188
|
+
* **service_hostname:** Hostname del servicio consumido.
|
189
|
+
* **request_uri:** Uri del endpoint consumido.
|
190
|
+
|
191
|
+
### Únicos para los métodos.
|
192
|
+
|
193
|
+
* **method:** Nombre del método que fue medido.
|
194
|
+
|
195
|
+
---
|
196
|
+
|
197
|
+
## Reportes.
|
198
|
+
|
199
|
+
El destino de los datos, una vez que son capturados y procesados, varía de acuerdo a las preferencias del usuario. Wor-Prof ofrece los siguientes destinos para la información:
|
200
|
+
* **LOGGER:** Utiliza Rails.logger para mostrar la información.
|
201
|
+
* **FILE:** Guarda la información en uno ó varios archivos de texto separados por coma (csv)
|
202
|
+
* **DATABASE:** Almacena los datos obtenidos en la misma base de datos que utiliza la aplicación Rails (requiere preparar el modelo, ver generadores/generador del modelo de datos)
|
203
|
+
* **EXTERNAL:** Realiza una petición POST con los datos enviados en el cuerpo en formato JSON. (requiere configuración adicional)
|
204
|
+
|
205
|
+
> Tanto "Logger" como "File" no necesitan configuración adicional para trabajar, sin embargo "Database" y "External" requieren pasos previos.
|
206
|
+
|
207
|
+
### Database Reporter
|
208
|
+
|
209
|
+
Para **DATABASE** es necesario generar un esquema que permita almacenar la información. Para lograr esto ponemos a disposición un generador, sin embargo, si se desea generar manualmente WProf necesita los siguientes modelos (se exponen los archivos de Migración).
|
210
|
+
|
211
|
+
> Modelo: WprofController
|
212
|
+
``` ruby
|
213
|
+
class CreateWprofControllers < ActiveRecord::Migration[5.0]
|
214
|
+
def change
|
215
|
+
create_table :wprof_controllers do |t|
|
216
|
+
t.string :transaction_id
|
217
|
+
t.float :total_time
|
218
|
+
t.datetime :start_dt
|
219
|
+
t.datetime :end_dt
|
220
|
+
t.integer :code
|
221
|
+
t.string :controller
|
222
|
+
t.string :url
|
223
|
+
t.float :db_runtime
|
224
|
+
|
225
|
+
t.timestamps
|
226
|
+
end
|
227
|
+
add_index :wprof_controllers, :transaction_id
|
228
|
+
add_index :wprof_controllers, :code
|
229
|
+
add_index :wprof_controllers, :url
|
230
|
+
end
|
231
|
+
end
|
232
|
+
```
|
233
|
+
> Modelo: WprofService
|
234
|
+
``` ruby
|
235
|
+
class CreateWprofServices < ActiveRecord::Migration[5.0]
|
236
|
+
def change
|
237
|
+
create_table :wprof_services do |t|
|
238
|
+
t.string :transaction_id
|
239
|
+
t.float :total_time
|
240
|
+
t.datetime :start_dt
|
241
|
+
t.datetime :end_dt
|
242
|
+
t.integer :code
|
243
|
+
t.string :service_hostname
|
244
|
+
t.string :request_uri
|
245
|
+
|
246
|
+
t.timestamps
|
247
|
+
end
|
248
|
+
add_index :wprof_services, :transaction_id
|
249
|
+
add_index :wprof_services, :code
|
250
|
+
add_index :wprof_services, :service_hostname
|
251
|
+
add_index :wprof_services, :request_uri
|
252
|
+
end
|
253
|
+
end
|
254
|
+
```
|
255
|
+
> Modelo: WprofMethod
|
256
|
+
``` ruby
|
257
|
+
class CreateWprofMethods < ActiveRecord::Migration[5.0]
|
258
|
+
def change
|
259
|
+
create_table :wprof_methods do |t|
|
260
|
+
t.string :transaction_id
|
261
|
+
t.float :total_time
|
262
|
+
t.datetime :start_dt
|
263
|
+
t.datetime :end_dt
|
264
|
+
t.string :method
|
265
|
+
|
266
|
+
t.timestamps
|
267
|
+
end
|
268
|
+
add_index :wprof_methods, :transaction_id
|
269
|
+
add_index :wprof_methods, :method
|
270
|
+
end
|
271
|
+
end
|
272
|
+
```
|
273
|
+
|
274
|
+
### External Request Reporter.
|
275
|
+
Una opción es enviar los datos por HTTP donde desee. Los datos obtenidos por Wprof serán enviados en el cuerpo como un JSON. Para que esto funcione bien es **necesario configurar la URL de destino**. La petición que se genera es POST y de ser necesario puede **configurar los HEADERS necesarios**. Si la URL no se configura, la petición no será enviada.
|
276
|
+
|
277
|
+
Las opciones a configurar son: external_url y external_headers. Consulte la sección de Configuraciones para más información.
|
278
|
+
|
279
|
+
---
|
280
|
+
|
281
|
+
## Asincronismo.
|
282
|
+
|
283
|
+
WProf por defecto reporta toda la información de manera ***sincronica**, sin embargo es posible configurar la herramienta para que este proceso lo haga de forma **asincronica**. Para lograr esto se debe en primer lugar activar la opción mediante la configuración del campo "config.x.wprof.async = true", sin embargo esto no es suficiente.
|
284
|
+
Para que todo el reporte se efectúe Asincrónicamente, es necesario tener funcional y operativo **Sidekiq**, ya que WProf lo utiliza para tal fin. Si no está familiarizado con la herramienta, puede buscar más información en el [repositorio de la misma haciendo click aquí!](https://github.com/mperham/sidekiq).
|
285
|
+
|
286
|
+
---
|
287
|
+
|
288
|
+
## Errores manejados.
|
289
|
+
|
290
|
+
Cualquier error dentro del proceso de captura y reporte de la información **NO DEBERIA** interrumpir el normal funcionamiento de su aplicación Rails. Si esto es así, por favor **reportelo**.
|
291
|
+
Durante la ejecución, podrían aparecer dos errores en el Logger de la aplicación.
|
292
|
+
|
293
|
+
```WProf ERROR when try parsing service response:``` Este error puede mostrarse si no fue posible capturar algún dato por parte de HTTParty.
|
294
|
+
|
295
|
+
```An error was raised when WProf tried to send data to reporter:``` Este es el error más típico y se mostrará en caso de que el envío de datos al destino seleccionado (es decir Logger, Database, File o External) haya fallado.
|
296
|
+
|
297
|
+
---
|
@@ -0,0 +1,42 @@
|
|
1
|
+
class WprofGenerator < Rails::Generators::Base
|
2
|
+
desc 'This generator creates an initializer file for Wor-Prof!'
|
3
|
+
def wor_prof_init
|
4
|
+
create_file 'config/initializers/wprof.rb', init_wprof
|
5
|
+
end
|
6
|
+
|
7
|
+
private
|
8
|
+
|
9
|
+
def init_wprof
|
10
|
+
<<~CONTENT
|
11
|
+
# -----------------------------------------
|
12
|
+
# Uncomment and set for use custom options.
|
13
|
+
# -----------------------------------------
|
14
|
+
Rails.application.configure do
|
15
|
+
## Save DB Runtime?: Default: true
|
16
|
+
# config.x.wprof.db_runtime = true
|
17
|
+
## Reporter Type (¿When we will save our data?): 'LOGGER' by default.
|
18
|
+
## Another options: 'FILE' (For CSV), 'DATABASE' (For Rails DB), 'EXTERNAL' (For external API).
|
19
|
+
# config.x.wprof.reporter_type = 'LOGGER'
|
20
|
+
## CSV Type (One CSV file for each type of data or all together)
|
21
|
+
## 'SPLIT' by default, Options: 'MIX'
|
22
|
+
# config.x.wprof.csv_type = 'SPLIT'
|
23
|
+
## Reporter must be work async? Default: false
|
24
|
+
# config.x.wprof.async = false
|
25
|
+
## Httparty Methods to wrapper.
|
26
|
+
# config.x.wprof.httparty_methods_to_trace = ['get', 'put', 'delete', 'post']
|
27
|
+
## External URL for hit when Reporter Type is EXTERNAL
|
28
|
+
## DEFAULT: nil
|
29
|
+
# config.x.wprof.external_url = 'http://example-url/reporter'
|
30
|
+
## Define Headers for Reporter Type when is EXTERNAL.
|
31
|
+
## Must be a Hash (see HTTPARTY doc for more info)
|
32
|
+
## DEFAULT: nil
|
33
|
+
# config.x.wprof.external_headers = { headers: {'User-Agent' => 'Httparty'}}
|
34
|
+
## Define your Custom Methods here! (Must be an Array)
|
35
|
+
# config.x.wprof.custom_methods = [ 'my_great_method' ]
|
36
|
+
## Define your own path for save Files when Reporter Type is FILE
|
37
|
+
## By default Wor-Prof use Rails.root
|
38
|
+
# config.x.wprof.file_path = '/home/mcolombo/examplefolder'
|
39
|
+
end
|
40
|
+
CONTENT
|
41
|
+
end
|
42
|
+
end
|
@@ -0,0 +1,14 @@
|
|
1
|
+
class WprofModelGenerator < Rails::Generators::Base
|
2
|
+
desc 'This generator creates all model for use Wor-prof witch reporter_type as Database'
|
3
|
+
def wprof_migrations
|
4
|
+
making_wprof_migrations
|
5
|
+
end
|
6
|
+
|
7
|
+
private
|
8
|
+
|
9
|
+
def making_wprof_migrations
|
10
|
+
generate 'model', 'WprofController transaction_id:string:index total_time:float start_dt:datetime end_dt:datetime code:integer:index controller:string url:string:index db_runtime:float'
|
11
|
+
generate 'model', 'WprofService transaction_id:string:index total_time:float start_dt:datetime end_dt:datetime code:integer:index service_hostname:string:index request_uri:string:index'
|
12
|
+
generate 'model', 'WprofMethod transaction_id:string:index total_time:float start_dt:datetime end_dt:datetime method:string:index'
|
13
|
+
end
|
14
|
+
end
|